Re: comments on new-model.txt

[Marius Vollmer <mvo@zagadka.ping.de>]

Lynn Winebarger <owinebar@free-expression.org> writes:

>    Marius has written a detailed proposal for a new model, most of
> which is dedicated to the nature of modules and scoping rules.

Ick, it's in CVS (workbook/compilation/), but I'm not yet really
prepared to defend it! ;)

Actually, I have tried to keep the module system out of the model as
much as possible.  The interface between the module system and a
hypthetical compiler is quite minimal.  The module system is very
important for the overall behavior of the system, but my intention is
to allow large changes to the module system without having to change
the compiler.

The biggest requirement that the proposal puts on the module system is
that modules can only ever grow; you can not remove bindings or change
existing ones.  I expect this to be a popular point for debate, and I
don't know if I can defend it successfully.  But the current model
rests on this requirement.

(When you want to change a module in a way that is not allowed, like
removing a binding, or importing a name from a different module, you
need to make a new module with the same name and fill it from scratch,
probably by recompiling/reloading it.  Modules that depend on your
module might also need to be recompiled/reloaded to pick up the
changes.  Maybe we can have support for constructing new modules in a
way that they export the exact same bindings that a given other module
does.  That way, the recompile avalanche could be stopped early.)

>     Marius' proposed system makes choices <open,open,interactive>.
> If by a module we mean a set of code that is meant as a unit for
> separate compilation, I believe the right choices are
> <closed,open,body>.

I hope that the model is 'open' enough to allow all variants.  I'd say
that when you have a model that allows <open, open, interactive>, you
can get the other variants via additional, external restrictions that
don't require changes to the model.

For example, the lexical option for (1) can be implemented within the
module system by allowing a module to be 'sealed' so that no further
bindings can be added to it.  That is compatible with the model.

Option 'closed' for (2) can likewise be implemented within the module
system by simply not offering any way to export names.  The model
doesn't care.

Option 'body' for (3) is harder to enforce in the module system, but
it is easy to add in the macro expansion pass which is also not
treated in detail in the proposal.

My goal for the new model was to specify something that would be
straightforward to implement, offer enough opportunities for a smart
compiler to optimize things, and still be reasonably flexible for
interactive use.

>     There is no reason to require macros to always be macros.  R5RS does
> not have any such requirement and there are plenty of compilers for it.

You can change a macro into a function, but you need to
recompile/reload your code for it to take effect.  That's about all
that the model implies.  Also, you can't redefine a name in a module,
but I think that is reasonable.

>      I do not agree with the stated use of the word "variable".  That term
> has such a standard definition that I believe it is only confusing to
> recast it to mean "generic box" (in the "smart variable" case).

Well, it's only terminology.  What you seem to call "variable", I
would call "identifier".  I agree that terminology is important,
ultimately, and I can change the word "variable" to "box" or
"location", but I don't want to be distracted by this just yet.

>     Rather than tying imported variables to solely to modules, I
> believe GUILE should adopt 2 new types of variables, extloc and
> extvar (or whatever) corresponding to ilocs and variables, but
> carrying a reference to their environment with them.  Space might be
> conserved by pointing into a table of environments rather than using
> a whole pointer.  In this way we can untie option 2 from options 1
> and 3.

I don't understand.  Can you explain?

>     To handle optimization, I believe we could adopt special forms
> that import values and bind them to local (possibly immutable)
> variables. [...]

This sounds more complicated than the 'declarations' feature of the
proposal.  The declarations have the advantage that you don't need to
do anything special when importing a name, the burdon is on the
definer of the name.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel