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

[Vesa Karvonen]

Quoting Matthew Fluet <fluet@cs.cornell.edu>:
[...]
> I'm still a little lukewarm on the idea;  I don't know of a compelling 
> usage scenario, which isn't to say there isn't one.

What I had in mind was that each project (product, application, library,
etc.) would have a configuration MLB file (or a few such files) that would
define the path variables used to refer to external MLB/SML files. Each
MLB file in the project would import the config MLB if it needs to refer
to external files. Configuring a project would mean updating the variables
in the config MLB file.

More concretely, a project would have files/structure like this:

   prj/config.mlb           (* var EXT_LIB_A=path-to-ext-lib-a
                               and EXT_LIB_B=path-to-ext-lib-b *)
   prj/sources.mlb          (* subdir-a/sources.mlb
                               subdir-b/sources.mlb
                               ... *)
   ...
   prj/subdir-a/sources.mlb (* local
                                  ../config.mlb
                                  $(EXT_LIB_B)/lib.mlb
                               in
                                  some-source.sml
                                  ...
                               end *)
   ...
   prj/subdir-b/sources.mlb (* local
                                  ../config.mlb
                                  $(EXT_LIB_A)/lib.mlb
                               in
                                  some-source.sml
                                  ...
                               end *)
   ...

Compared to the current ML Basis system, this would be different in that
the source of path variables is specified in the MLB files.

> It just seems to me that if you have something like:
> 
> var V1=d0
> $(V1)/s1.sml
> $(V1)/s2.sml
> 
> where you are importing multiple .sml files from the same path, then it 
> would be a good practice to define a single .mlb file in that directory:
> 
> var V1=d0
> $(V1)/s.mlb
> 
> in which case, there isn't much advantage to a path variable:
> 
> d0/s.mlb

Yes, I agree. It seems that path variables make most sense when
their values are specified outside the MLB file that refers to them.
Being able to specify local path variables in an MLB file may
sometimes be useful for abbreviating paths or for improving
readability (giving an intentional name to a complex path), but the
benefit is likely to be minor.

...

The similarity between MLB bases and SML structures makes me wonder
about the need for something like functors (and signatures) at the MLB
level. It would allow one to express the notion of a "parameterized
basis" and lexically scoped path variables would then make more sense.
However, it is most likely to be a major overkill with minimal practical
benefit. (I'm not implying here that defining path variables like I
illustrated above would not make sense.)

-Vesa Karvonen