[MLton] MLton library project licensing

[Stephen Weeks]

I also like the idea of having both per-repository and per-library
branching.  One of the design goals of MLBs was to support such
flexible schemes, in which multiple revisions of a library are extant
in the same program.

I have one thought about improving the per-library branching.  As a
reminder, here's the suggested layout and idea behind it.

>   a/
>     r1/ ... library a files ...
>     r2/ ... library a files ...
>     ...
>   b/
>     r1/ ... library b files ...
>     r2/ ... library b files ...
>     ...
...
> The idea here is that a new "revision" is started when incompatible
> interface changes are needed.
...
> the revisioning (or branching) is made visible to the users and they
> can directly refer to any of the supported revisions of a library.

What if instead, we made every library revision (e.g. a/r2)
immutable.  Then, an under-the-hood "bug fix" to a library couldn't
break user code that relied on the "feature".  Library users really
would be guaranteed that if they referred to a library then the
behavior wouldn't change.  Immutability includes references to other
libraries as well, so if one library wants to upgrade to use new
revisions of another, it's revision number must change.  The behavior
of a library revisions really is completely fixed.

The layout then includes a separate "unstable" directory for each
library (e.g. a/unstable), in which development of various revisions
of the library occur (e.g. a/unstable/r5).  The act of copying a
revision from the unstable directory to the library directory
effectively tags it and freezes it for all time.

As to using this with MLBs, the path variable approach seems like a
good one.   I wonder if it would be useful to have a little extra
tool support so that one could use explicitly use the unstable head of
a library, e.g. with

    LIB_A $(LIB_COLLECTION)/a/head/lib.mlb

and then when one wants to ship a package (be it a library or end-user
code) one can automatically go through and turn all of the references
to "head" into the library revision they actually refer to.  The idea
being to make it easy for users to just use libraries without having
to dig through the source and find revision numbers, but then easily
be able to freeze their dependencies when they're happy.