Re: [MIT-Scheme-devel] Module system?

[Taylor R Campbell]

   Date: Sat, 29 Aug 2009 18:31:05 -0700
   From: address@hidden (Matt Birkholz)

   I also read Taylor's bug report #15020, which observes that variables
   syntactically closed in any environment but () cannot be fasdumped.
   The syntactic closures refer to environments, which refer to...
   basically, everything.  I infer that if I succeeded in closing
   call-alien in (ffi macros), I would not be able to fasdump any
   expansions.

The main problem here is that the compiler/linker and the macro system
fail to communicate, and that the macro system uses the wrong data
structure, interpreter environments.

   I would like to fix my problem (and 90% of Taylor's?) by expanding
   such a variable reference into a peculiar free variable reference.
   My C-call syntax would expand into a reference to call-alien closed in
   (runtime ffi), and the file syntaxer would expand this into a free
   reference to a binding named |call-alien(runtime ffi)| (uncapturable
   by convention?).  Fasload then links the "free" variable binding to
   the appropriate source binding at load time.  Simple?

   I can't take credit for the idea.  I heard basically the same proposal
   many years ago (from Jinx?).  I could hardly appreciate the finesse in
   the solution (nor even the problem!) at the time.  Now... I *need* it!

If we're happy with universal names for modules, that works.

But what happens when someone else writes a different program called a
`compiler', or a program to transmit distress signals in Morse code,
and wants to load it into an image that already has LIAR and the
Scheme Object System loaded?  Without a naming authority -- which
could be so simple as (quite literally speaking) a URI authority --
universal names are not practical.

Universal names for modules and bindings are not necessary, however,
to make a system work.  In Scheme48, modules and environments are only
necessarily part of the compiler and linker; compiled code need know
only about value cells, which the compiler and linker set up.  (The
macro system, incidentally, is part of the compiler, not the run-time
system.  In MIT Scheme the situation is complicated by the existence
of a separate interpreter which also uses the macro expander.)
Systems such as the interactive command processor (the REPL) are built
`reified': the linker links them and reifies their modules and
environments so that they can refer to their own modules and
environments.  (The linker thus acts like the U combinator.)

   The project homepage says that we plan to implement a module
   system(!).  I assume the above issues are in the bailiwick of that
   effort.

   Is there a sketch of the desired "module system"?

Chris and I have very different ideas of what a module system should
look like.  For a discussion of some of the issues surrounding module
systems for Scheme, see Flatt, `Composable and Compilable Macros: You
Want It When?', 2002.  CREF is not really an appropriate starting
point -- aside from its failure to record actual dependencies, rather
than just environment linkage, in order for any of this to work well,
the compiler/linker and macro system have to communicate.