Re: Dybvig's module system and interactivity

[Mikael Djurfeldt]

Mikael Djurfeldt <address@hidden> writes:

> > OK, so if using import within a local scope is a bad thing, why not just
> > restrict its use to the top-level?  Sure, you could do that.  However, in
> > this case all the examples from Dybvig's paper (the implementation of
> > "from", "define-alias", ...) have to be implemented differently, because
> > their implementation depends on using "import" in a local scope.  In other
> > words, we would have to implement all interesting primitives for module
> > handling as if we would be starting to write a new module system on our
> > own anyway.
> 
> What are you saying?  It seems to me that the core of this argument
> is: Dybvig's system has these extra features not found in other module
> systems.  If we use them, we run into trouble.  But if we don't use
> them we don't have all these nice extra features.  Therefore, Dybvig's
> system has a problem.

A clarification: I don't think the fact that the power of the import
macro in itself is a reason not to use it.  One can do a lot of ugly
things with lambda for that matter.  It is not our role to force
certain usage patterns upon users.

It is quite possible to restrict oneself to only using the import form
at the top of the file.

However, there are other reasons for implementing a second layer of
macros, and basing these upon the underlaying module and import forms
will probably yield something beautiful.


Another thing: Note that we have had as one requirement to have a
module system which can scope syntax.  But this of course means that
we need to know the transformers of imported modules, also during
separate compilation.  So, I don't think Dybvig's system has bloodier
requirements than other systems scoping syntax...