This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: A module system should resolve, not introduce, name conflicts



I think the limitation you're really pointing out in that digest of
messages from comp.lang.scheme is that MzScheme's units can't scope
syntax.  I think units are nice in a lot of ways, but this seems like
a pretty serious limitation.  I don't think that Guile should adopt a
module system that doesn't allow modules to export syntax.

Rees' module system brings the entire language, including its
syntactic bindings, under the control of the module system, which is
quite beautiful.

I managed to obtain a copy of Richard Kelsey's NEC technical report
describing his new module system.  (It's not available for download,
as far as I can tell; the NEC secretary very kindly mailed me a copy)
I haven't read it through yet, but I did find a paragraph suggesting
that one could use it to scope syntax, which is promising.

I think there are a lot of messy questions here, including: what does
it mean for a module to export both syntax and variable bindings?
Suppose module A imports module B, and that module B exports a macro
which affects the value of an exported variable --- say, it
accumulates a table computed from each macro invocation.  This
arrangement will work in an interpreted environment, where it's
translated and executed at the same time, but it will fail in a
separate compilation environment, in which module A is first compiled,
and then executed much later, possibly as part of a different process
from the one that expanded the macros.

I mean, you could certainly say, "Don't do that."  But it would be
nice to look for a more satisfying solution.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]