Bengt Kleberg (firstname.lastname@example.org) wrote:
> But surely there are some Scheme systems that have modules? Perhaps they
> are a good starting point? If the CL system is ok, why not use it?
The question is what you want to do with modules, what your general
translation model is like, and why you're going for Scheme in the first
place. CL is a very powerful and non-trivial system, and picking pieces
out of it and transferring them to Scheme won't always create anything
with the original consistency and usability, nor would it necessarily
fit to Scheme's somewhat different approach. If you want something
mostly like CL, you should probably just use CL and adapt those areas
which you don't like, instead of trying to make Scheme look like CL.
There's quite much flexibility in CL to help you perform such things.
I for one don't think CL's package model fits Scheme very well;
something like multiple lexical top-level environments with imports
as read-only access to top-level bindings of other modules would be
preferable. Add a simple way to have macros ask for translation-time
import of modules and elaboration of initializations, and you've got
a reasonably flexible model (leaving things like module redefinition
to the development environment, perhaps with something like "open mode"
and "closed mode" for modules, the latter allowing more optimizations,
like direct calls and inlining, for those definitions which aren't
set! in their defining module). If people want it, this could be
extended with facilities for dynamic module manipulation (making them
into mutable environment objects), but IMO code which doesn't depend
on such dynamic facilities should be easily recognizable as not doing
so, supporting a mostly declarative/functional programming style and
a reasonably straight-forward static analysis of dependencies.
-- Marc Wachowitz <email@example.com>