[MLton] mlnlffigen is awesome (was: bootstrap problem)

[Matthew Fluet]

> > is there a reason why the ML Basis system does not support binding
> > path variables in the MLB files?
> >
> > I'm just wondering about the need for three levels of source files:
> > 1. SML files
> > 2. MLB files
> > 3. MLB Path Map files
> > 
> > Wouldn't it be simpler if there were just two levels:
> > 1. SML files
> > 2. MLB files (with the ability to bind path variables; importing
> >               a basis would bring the path variables to scope)
> 
> This is not to say that your suggestion won't work; just that it needs
> some thought and some playing around with the MLB semantics to get a
> feel for what it might look like..  Please feel free to run a proposal
> by the list -- no need to tex it up, ASCII art inference rules are
> fine.

I believe that changing the MLB path variable environment during 
elaboration would seriously alter the semantics of "caching" a previously 
elaborated .mlb file, which is a very important aspect.

For example, consider the following file structure and file contents:

foo.mlb
bar.mlb
baz.mlb
util/util.mlb
util/aaa/sources.mlb
util/bbb/sources.mlb

foo.mlb:
  bar.mlb
  baz.mlb

bar.mlb:
  local
    var AUX = "aaa"
    util.mlb
  in
    a.sml
  end

baz.mlb:
  local
    var AUX = "bbb"
    util.mlb
  in
    b.sml
  end

util/util.mlb:
  local
    $(AUX)/sources.mlb
  in
    x.sml y.sml z.sml
  end


Are {x,y,z}.sml elaborated (and evaluated) once or twice?  The current
semantics demand that they be elaborated (and evaluated) exactly once, 
because the denotation of "util/util.mlb" is fixed.

With MLB path variables in the MLB files, then bar.mlb clearly expects
a.sml to be elaborated and evaluated in an environment where {x,y,z}.sml
are elab/eval-ed in the util/aaa/sources.mlb environment, while baz.mlb
expects b.sml to be elab/eval-ed in the util/bbb/sources.mlb environment.

Note that you can't make the decision on whether or not to re-elab/eval
util/util.mlb based on the expansion of its path, as that is invariant
under changes to the MLB path map.  Conservatively, you could re-elab/eval
a .mlb whenever the MLB path map differed from a previously cached 
elaboration of the .mlb, but this would unacceptably break sharing 
(consider the consequences of elab/eval-ing $(SML_LIB)/basis/basis.mlb 
more than once).  Even re-elab/eval-ing when a relevant MLB path variable 
changed (i.e., by computing the free MLB path variables, though even that 
is an ill-defined notion, as what other .mlb files are reachable from one 
.mlb file depends on the current MLB path map) seems like it would have 
horribly complicated semantics.