Re: New module system

[Mikael Djurfeldt]

Dirk Herrmann <address@hidden> writes:

> > > IMO, this is a flaw in the system in general:  The semantics of the
> > > example code above is completely dependent on the set of identifiers that
> > > is provided by M.  Changes to M can have fatal consequences on code that
> > > imports M, even in a compiled environment.  In other words:  You rather
> > > don't use import, but only one of the derived forms (like 'from').
> 
> We want modules in order to allow separate development of code.  The
> developer of module M might decide to change M such that a newer version
> would export a binding for 'y.  With Dybvig's system, this is extremely
> dangerous, since all code that made use of M would break if that code used
> a local variable 'y, because due to the change to M, bindings to local
> variables would be changed.

There must be some misunderstanding here.  If Dybvig's system is used
as any other module system, it is *as* dangerous as that system, not
more dangerous.

Of course, if a Dybvig module is imported *within* a lexical
environment, it can shadow bindings.  In most other module systems,
you can't do that at all.  I think Dybvig's paper makes it clear how
useful this mechanism can be.