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

[Vesa Karvonen]

Quoting Matthew Fluet <fluet@cs.cornell.edu>:

> > > 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.

Yes, it definitely needs some work, but I think that it isn't yet clear
whether the feature makes sense or not, and that there is room for some
informal discussion before drafting a formal proposal.

> 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.

I agree. That is why I chose to use the term "import" rather than
"elaborate" earlier. What I basically meant is that an MLB file
would not have free variables (which may be impractical). Here is a
quote from the http://mlton.org/MLBasisSyntaxAndSemantics page:

  "Recall that an ML basis file is elaborated in an empty basis; hence, no
   bindings from the "current" basis are available to the imported basis
   file."

What I had in mind is that path variables would work just like other
bindings; Path variable bindings imported from a basis would only effect
paths in the scope of the import. Consider the following pseudo code:

  var V1=d0
  $(V1)/b1.mlb  (* "d0/b1.mlb" contains "var V1=d1 and V2=d2" *)
  $(V1)/b2.mlb  (* expands to "d1/b2.mlb", which contains "var V2=d3" *)
  $(V2)/s1.sml  (* expands to "d3/s1.sml" *)
  $(V1)/s2.sml  (* expands to "d1/s2.sml" *)

The above merely illustrates the idea that importing a basis may introduce
path variable bindings. Now, consider the following pseudo code:

  var V1=d1
  $(V1)/s1.sml  (* expands to "d1/s1.sml", which contains some valid SML code *)
  $(V1)/b3.mlb  (* expands to "d1/b3.mlb", which contains "$(V1)/s1.sml" *)

The above would fail during elaboration of "d1/b3.mlb", because the path
variable V1 is not bound.

> For example, consider the following file structure and file contents:
[...]
>   local
>     var AUX = "aaa"
>     util.mlb
>   in
[...]

The binding above, var AUX = "aaa", would have no effect on the
elaboration of util.mlb:

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

util.mlb would fail to elaborate due to the reference to an unbound path
variable AUX.

-Vesa Karvonen