[R6RS] Re: strawman module syntax

[Richard Kelsey]

   Date: Fri, 9 Jul 2004 14:28:13 -0500 (EST)
   From: "R. Kent Dybvig" <dyb at cs.indiana.edu>

   2. Treat both module and require (import) forms as definitions and
      allow them to appear anywhere where other definitions can appear.
      As with top-level definitions, top-level module forms may allow one
      to do things that don't make sense for internal module forms.  I
      see no harm in this.  Experience has shown that disallowing
      internal define-syntax was a bad idea; let's not repeat the mistake
      with modules.

My experience has been that allowing internal define was a
bad idea.  I am glad that we did not repeat the mistake with
define-syntax.  Which isn't so say that I can't be conviced
that internal import forms should be allowed, just that you
can't appeal to my experiences with internal define and the
lack of internal define-syntax as a talking point.

   4. Don't force the use of separate interfaces, i.e., allow one to
      require a named module rather than a named interface.  Don't support
      separate interfaces at all unless we have some portable mechanism
      for specifying which of multiple implementations is to used.

      There's no point in separate interfaces if only one implementation
      is available.

I strongly disagree with this.  It can be very helpful to 
have separate interfaces even if only one implementation
of each is available.  If I am looking at module X I want
to be able to tell where its imported bindings come from
without having to look at the source for modules Y and Z.
I can't do this if Y and Z's export list is mixed in with
their source.

Yes, this does result in name duplication.  In my experience
is that it's worth it.  Your mileage may very.

   5. If we do support separate interfaces, they should include exported
      syntactic abstractions along with any nonexported syntactic
      abstractions (and meta definitions, if we support them) into which
      exported syntactic abstractions use or expand.

      Virtually nothing can be done with code that imports from an interface
      without the syntactic abstractions, so there's no point in knowing
      the interface before the syntactic abstractions are known.

For a person reading code that imports an interface it is very
helpful to know what is and what is not an a syntactic abstraction.
It lets them know what they have to go look up.

If there are no exported syntactic abstractions, as there often
aren't, or if the importing code doesn't use them, this knowledge
that is quite valuable for both people and implementations.

   ... I prefer to require hidden exports to be named (which we
   must do anyway if we ever go the route of separate interfaces),

Scheme 48 has separate interfaces and does not require that
hidden exports be named, so I am not sure what you mean here.
In the presence of exported modules the Scheme 48's separate
interfaces are insufficent to allow separate compilation, but
that isn't what they're for.
                                     -Richard