Re: PLT Scheme development directions

[Matthew Flatt <mflatt@cs.utah.edu>]

Quoting Mark Seaborn:
> > We have a variable to use in each of u1 and u2, but there are no
> > variable definitions - the variables don't actually exist!
> > 
> > The `compound-unit' form could, of course, detect such cycles, assuming
> > that a unit provides information about its re-exports. But the
> > underlying problem would make the semantics and implementation of units
> > far more complex, so we chose to avoid the problem by disallowing
> > re-export.
> 
> I can see how implementing this could be tricky.

I'd claim it's not really an artifact of the implementation, but of the
fact that units to import/export locations rather than values.

> My implementation of units doesn't have the luxury of dealing with
> locations directly, 

Neither will the unit implementation in the next release of MzScheme,
since `unit' will be just a fancy macro. (The `invoke-unit' form will
become a little weaker.)

> so, during unit invocation, when a value is bound
> (by evaluating a `define' form in the unit), the code just ensures the
> value becomes visible in units which import the variable by `set!'ting
> it in their environments.  In this model, re-export of variables is
> not a problem, because it can be done the same way as normal
> exporting.  If a cycle occurs (as in your example above), the variable
> just never gets initialised.

If I understand correctly, you have in mind implementing import/export
of values instead of locations, plus an intialization strategy that
makes it possible to define mutually recursive procedures across
components boundaries. I'll have to read your design details more
closely, but it sounds plausible.

> There's obviously the question of why I wanted to do re-exporting of
> variables to start with.  It wasn't actually a very good reason:  I
> wanted to be able to avoid duplicating signature restrictions all over 
> the place in a compound-unit/sig form.  I thought maybe I could pass a 
> tag to a unit which just re-exported its import with a restricted
> signature, and bind the result to a new tag.  Not elegant at all, and
> it also doesn't work.

That sounds like a job for compound units.

> But I can imagine there are good reasons for wanting to do re-export,
> such as extending a unit to export more variables.  This can be done
> with PLT units, but only at run time -- it can't be done within a
> compound-unit/sig form -- which means that you can't have unit
> invocations be shared.  The unit being extended (if it is extended
> more than once) may get invoked multiple times, which is wasteful.

This sounds like the kind of thing compound-unit/sig would do, though.
Is the problem that you imagine a kind of mixin compound that adds
exports to an arbitrary unit (which can't be done with c-u/s)?

> What it all boils down to is the problem that compound-unit/sig isn't
> expressive enough.  You can't put a conditional inside it, 

You can put a conditional in each expression position that determines a
constituent unit...

> so if it
> contains a set of units that can be replaced by another set of units,
> these sets must be lifted out into their own compound-unit/sig forms.
> This involves lots of plumbing of imports and exports between the
> different linking statements, which is fiddly and inelegant.

I'm a little lost here.

> The basic problem is that unit *invocations* can't be passed around at
> the Scheme level, they are confined to the unexpressive language of
> compound-unit/sig. 

It's certainly true that invocations can't be passed around. This is a
conscious and carefully maintained design choice. It forces
library-like units to the top of the hierarchy; that can be incovenient
to some programmers, but makes the overall program more configurable
for other programmers.

> Units themselves can be passed around at the
> Scheme level, which is wonderful, but you can't really use this
> ability to link complex programs together, because unit invocations
> end up not being shared, and units can't be mutually linked at this
> level (the main advantage of units).

Dynamic linking via `invoke-unit' permits sharing. It does force the
linking structure upside-down though -- again, a conscisous design
choice aimed at exposing the way a program is linked and where it
should be parameterized.


I'll have to look at your design and think more about the trade-offs of
importing/exporting values versus locations. I havne't really thought
about combining the former with an initialization process that makes it
easy to express mutual recursion across units.

Matthew


_____NetZero Free Internet Access and Email______
   http://www.netzero.net/download/index.html