[R6RS] proposed library/syntax-case changes

[dyb at cs.indiana.edu]

After working on the library and syntax-case implementation with Aziz
Ghuloum, I would like to propose several changes.

* restrict declarations to the front of a library or lambda body.  (At
  present, they are also allowed at the front of a begin that contains
  only definitions.) This restriction simplifies both the grammar and
  implementation.  In the future, we can consider a splicing form like
  let-syntax and letrec-syntax (let-declaration?) for wrapping definitions
  around a sequence of declarations.  I believe that Mike has already
  made this change in the library text to resolve an ambiguity in the
  syntax.

* flush syntax-lambda.  We started to work this in and discovered that
  it is incompatible with the existing variable-transformer procedure.
  We considered other changes to the syntax, but Aziz finally convinced me
  that my reasons for advocating such a feature were bogus.  As Will
  pointed out, one can recognize syntax-case by the *lack* of a specific
  keyword following 'define-syntax name', so this doesn't preclude the
  use of implementation-specific mechanisms or future extensions, which
  can be made by introducing such keywords or new procedures like
  variable-transformer, we avoid gumming up the syntax for standard
  R6RS macro definitions, and we avoid invalidating the existing corpus
  of syntax-case macro definitions.

* refine the library-body semantics so that library bodies expand into
  into the equivalent of the following:
  
      (letrec* ((var rhs) ...) ; bindings for all defined variables
        init ...               ; all of the commands following definitions
        (once-only)            ; unspecified behavior if evaluated twice
        (export evar) ...)     ; initializes export locations

  where {evar, ...} is the exported subset of {var, ...}.  This
  change simplifies the body expansion (and documentation) and makes it
  easier for an implementation to optimize references to exported
  variables within the exporting library.

* flush "for eval".  Aziz pointed out correctly that requiring "for eval"
  to be present in the library header effectively prevents people from the
  full freedom to exercise functionality that is present in most other
  languages, like C (with dlopen/dlsym) and Perl (with dynamically loaded
  modules), putting Scheme at a competitive disadvantage.  This means, for
  example, that we can't implement a Linux-like kernel or Apache-like web
  server with dynamically loadable modules.  We can't even use the system
  to implement a portable interactive Scheme REPL and interpreter with
  dynamically loaded libraries. 

  Furthermore, the "for eval" syntax has various issues.  It's not clear,
  for example, how it should affect the set of libraries that can be used
  for eval when the library containing the form is expanded, and it's not
  clear what effect, if any, renaming or restricting the set of bindings
  imported "for eval" should have on the import-specs given in the
  environment form.

  For the many applications that don't use eval, removing the "for eval"
  declaration and corresponding restriction does not impact an
  implementation's ability to generate self-contained applications. 
  Implementations may of course include implementation-dependent
  extensions to limit the damage when eval is used.

In the spirit of compromise, I'm willing also to flush indirect-export
forms, which I think no one else has favored.  This will prevent us from
eliminating useless local library bindings, but with immutable exports,
this should be the only downside.

Kent