[R6RS] modules?

[Michael Sperber]

>>>>> "Marc" == Marc Feeley <feeley at IRO.UMontreal.CA> writes:

Marc> My main issue with Matthew's proposal is that I don't understand how
Marc> the pieces of code (the modules) are put together to form a program.
Marc> This is a central issue because there are different kinds of
Marc> "programs" that should be possible:

Marc> 1) standalone statically linked program [...]
Marc> 2) dynamically linked program [...]
Marc> 3) scripts [...]
Marc> 4) REPL-style "program" [...]

Marc> I would like a module system that works well in all these situations.

I don't think a characterization like this is terribly useful,
especially as these terms are very much open to interpretation.
Matthew has pointed out that MzScheme's system supports all of those
bullets in some sense, but possibly not in the sense somebody else
might interpret them.  In particular, some interpretations of some of
those terms might just mean that you need another "module system" to
cover it.

For instance, MzScheme's MODULE construct supports dynamic linking in
some sense, but it's too weak to support dynamic program assembly the
way MzScheme's UNIT system does.

Moreover, "works well" is also a pretty flexible term.  For me, that
would include things like separate compilation, importing modules into
local environments, a separation of interfaces and implementation, and
full parametricity---in certain contexts, but possibly not the context
of the R6RS module system.

As all of this is such a mess, I again suggest that we simply take
Matthew's proposal as a starting point for the "first" module system
we put into R6RS and keep in mind that additional features we want
should maybe end up in another (kind of) module system.

-- 
Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla