[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New module system
From: |
Mikael Djurfeldt |
Subject: |
Re: New module system |
Date: |
18 Dec 2000 15:05:06 +0100 |
User-agent: |
Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 |
Michael Livshin <address@hidden> writes:
> Mikael Djurfeldt <address@hidden> writes:
>
> > Note that Dybvig's system is entirely at the syntactic level. It
> > requires no special support in the evaluator since the syntactic
> > forms of the module system will be expanded away when the evaluator
> > starts building lexical environments.
>
> so this means that the module system as is is "invisible" after the
> expansion, right?
Right.
> this also means that the module system's "entities" can't be reified
> on the C level, right?
No, it would still be possible to have a C API to the module
system---to create modules, export bindings etc. Also, note that we
would build a layer on top of the low-level "module" syntax. This
layer would handle mapping to file names, dynamic loading etc.
(As a demo, Dybvig and Wadell have actually implemented MzScheme's
unit system on top of the "module" syntax!)
> > The basic problem you are addressing is essentially what to do with
> > already expanded code when a macro definition is changed. Should we
> > or should we not re-expand code using the new definition?
> >
> > I've never seen a system which re-expands code, but maybe this is
> > possible?
>
> FWIW, the Common Lisp systems I've seen don't re-expand code when a
> macro definition changes.
Still, it's an interesting idea to think about. It might turn out to
heavy to implement, but would definitely assist development.
Re: New module system, Mikael Djurfeldt, 2000/12/18
Re: New module system, Jim Blandy, 2000/12/18
Re: New module system, Mikael Djurfeldt, 2000/12/18
Re: New module system, Jim Blandy, 2000/12/19
Re: New module system, Mikael Djurfeldt, 2000/12/19
Macro uexpansion, Mikael Djurfeldt, 2000/12/19