[MIT-Scheme-devel] Module system?

[Matt Birkholz]

I love CREF.  It is a great help.  Its configuration files are second
only to the TAGSs in my list of favorite references.  However... :-)

I tried to hide the procedure call-alien behind my C-call syntax,
exporting just the latter.  I was hoping my reference to call-alien
would be closed in (ffi macros), but I get a free reference.  For now
I export call-alien to () and ignore the risk of capture.

SOS does better.  Its macros use a procedure named "absolute" that
replaces variables that should be closed in (sos macros) with e.g.
(access add-method system-global-environment).  An export, e.g. from
(sos method) to (), makes that work.

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.

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!

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"?