[R6RS] Re: strawman module syntax
Sun Jul 11 11:41:07 EDT 2004
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
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
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
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.
More information about the R6RS