On 1/25/06, Lauri Alanko <xxxxxx@iki.fi> wrote:
>
> "scheme://r6rs" -> (scheme r6rs)

This does add some ambiguity with the current import syntax.  Does

  (import (add-prefix foo bar))

mean to add the "bar" prefix to module foo, or does it mean to import
the single module name (add-prefix foo bar)?  In this case we can
unambiguosly determine that it is in fact the latter, because foo
should be (foo) if it were a module, but this seems a rather weak
distinction, and breaks easily with other extensions to the import
specification.

You could easily enough provide import-prefix, import-rename,
etc. syntax to unambiguously import modules named by arbitrary sexps,
however these can't nest without the same ambiguity arising.

One way to disambiguate would be to give the module name a single
fixed position in all import statements (requiring a separate import
clause for each module):

  (import <module-name> <import-modifier>*)

where the <import-modifier>s could be any of

  (only <identifier>*)
  (except <identifier>*)
  (rename (<identifier> <identifier>)*)
  (add-prefix <identifier>)
  (for <phase>*)

and the modifiers are applied in the order they appear.  So the
example from the draft:

  (import (only "stack" make push! pop!)
          (add-prefix "balloons" balloon:))

becomes (modulo any changes to the module naming convention)

  (import "stack" (only make push! pop!))
  (import "balloons" (add-prefix balloon:))

and a nested example would be to translate

  (import (add-prefix (rename (only "stack" make push! pop!)
                              (make create))
                       stack:))

to

  (import "stack" (only make push! pop!)
                  (rename (make create))
                  (add-prefix stack:))

which to me at least seems easier to parse and reason about.  Humans
always know right away from the first argument what module is being
imported, and machines no longer have to worry about ambiguities,
freeing up discussion for arbitrary module naming conventions.

--
Alex