[MLton] MLB path variables and path maps

[Stephen Weeks]

> It occurs to me that the ability to specify path variables in MLB files
> and consequently the ability to have a single name be bound to different
> values in a single compilation does solve one real problem. The problem
> is that of depending on multiple versions of a single library. If path
> variables are specified as they are now, there is no way to compile an
> application that needs multiple versions of a single library without
> introducing additional path variables and changing (potentially lots of)
> MLB files to refer to the new path variables.

I agree we want to support the easy use of multiple versions of a
library and cannot now easily do so.  I also agree that one does not
want to have to go in and hack the MLB path variables, and that having
local path variables inside of MLBs allows one to centralize things so
that version numbers could be expressed and changed in a single place.

What I'm not sure of, and don't think we have enough to go on, is if
using path variables in MLBs is the right way to express version
dependencies between packages.  Offhand, it feels like a pretty weak
language to me (e.g. how could you express that any version between
1.5 and 1.9 of some package is OK).

I think this use can only be evaluated in the context of a packaging
system for MLBs, which alas we haven't even seriously discussed yet.