Re: comments on new-model.txt [long]

[Marius Vollmer]

Lynn Winebarger <address@hidden> writes:

>      The problem is the very definition of what modules are.  That's
> what I'm objecting to, and it is in there.  I can only assume this
> is in preservation of the current module system,

Yes.

> which is way too dynamic in nature.

Others will disagree.  If we _can_ have meaningful compilation
together with our current, dynamic module system, we should offer it.
A more static module system might allow better compilation, and we
should try to not prohibit such a module system.

Pretend that you have a Guile that implements the model as written
down, with our current dynamic module system (or a slight variant of
it).  Assume that you have a specification for a new, static module
system that you want to use with Guile.  Is it possible to implement
the new module system in such a way that the old compiler can generate
code for it?  (The code must only be correct, it must not be very
good.)  If not, what parts of the model stand in the way?

What do you need so that the new module system can communicate with a
new compiler, so that the new compiler can generate better code or
produce better error messages, and can still generate correct code for
the old module system?


In any way, I don't see how we can proceed when we first need to agree
on a new module system.  The current system is widely used and we can
only improve upon it in small steps.  The 'new model' is a somewhat
big small step, but I'm afraid we will not move at all when we don't
make that step "because it is too small".

> > 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.
>
>       The biggest one is that there's a "current module" at evaluation
> time and that it can be changed.  That's a _huge_ requirement.

I can't cleary see how you can do without a current module.  It might
not be an explicit global variable, but just as there is always a
current lexical environment, there will be an associated current
module, in my view.

Can you sketch how the module system would work without a current
module?

> > 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.
>
>       But, as I understand it, this is one of the problems that has
> been encountered in practice (the interaction between macro expansion
> and the "module" system).

As far as I know, the problems stem from our imperfect integration of
the macro expander and the module system, and because we currently
expand macros lazily.  Although this issue is not addressed directly,
the new-model does not prohibit us to get it right.

> > >     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.
> 
>      I almost always prefer code I'm using not to have some oddball
> implicit semantics.  If it's going to do something weird, I should specify
> that it does something weird.

Yes, I agree.  The declarations should not be used to do something
weird.  The declarations can carry information about types of returned
values when you want to allow the compiler to make use of this
information.  The most concrete declaration that I have in mind right
now would be used to tell the compiler things like "this variable
always holds R5RS 'car', feel free to produce inline code".

But I start to think that we should allow declarations in other
places, not just when defining a variable.  You might want to import a
binding and tell the compiler that it should/should not inline the
contained function, say.

So what about moving declarations from variables to bindings?  When
you import a binding, you get a new copy and can add to the
declarations without affecting the declarations of the original
binding.

>     I don't think it will hurt to reflect on this statement from
> R5RS either:
> 
> Following Algol, Scheme is a statically scoped programming language.
> Each use of a variable is associated with a lexically apparent
> binding of that variable.
> 
>    Now you may think I'm being pedantic, but I think discarding that
> second sentence should at least give pause.

Yes.  But is R5RS true to this sentence itself?  What about 'eval' and
'load'?  Is it appearant to what variables a free reference in a form
passed to 'eval' is associated with?  What about a loading two files
in succession where the second file uses a variable defined in the
first?

> >Is this related to the 'module' feature of recent versions of Dybvig's
> >syntax-case implementation?  If so, I think that it is implemented
> >solely with renaming of identifiers and needs no support from the
> >interpreter.  Also, I think that the syntax-case modules are less
> >powerful than ours since their semantics are fixed while ours can be
> >cleanly extended.
> 
>    To the extent that we're talking about lexically scoped closures
> with exportable bindings, yes I suppose.  Though I'm not sure
> what you mean by "cleanly extended".  Maybe you can give
> an example of what you mean.

Hmm, scratch the "cleanly extensible".  I was thinking about how our
modules are implented as some data structures with associated
operations and how you can work on these data structures and operation
as long as you maintain the interface to the interpreter/compiler.
Dybvig's macros are hackable as well, of course, and maybe more
cleanly.


I'll reply to the rest in a separate mail.

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