[MLton] MLB path variables and path maps

[Vesa Karvonen]

Quoting Stephen Weeks <sweeks@sweeks.com>:
[...]
> The upshot of my study is that, as far as I can tell, MLB path
> variables exist for a sole simple purpose: to refer to standard
> libraries in MLB files without using hardwired absolute paths.  MLB
> path maps (and ~/.mlton/mlb-path-map) are there to provide the user a
> convenient way to refer to their own libraries in MLB files without
> using hardwired absolute paths.
> 
> Given this very simple purpose, I'm not convinced of the need for a
> more complex mechanism in which path variables are defined in MLB
> files.  It may be that such a mechanism would solve some other problem
> -- I think it would be worth articulating that problem before
> attempting a solution.

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.

Having the ability to bind path variables in MLB files also alleviates
the problem of reserving names for path variables:

> Matthew:
>
>   Also, looking forward to future libraries, I'm wondering if SML_LIB
>   is the best name for the root, and where should it be initialized.

With the ability to define path variables in MLB files and the ability to
control their scope (like with other bindings) makes it possible to use
a single name for multiple purposes. I could use SML_LIB to refer to my
own SML utility library (I actually did so for a short time, but changed
it to SML_UTIL after noticing that SML_LIB was already "reserved") inside
my MLB files without fear of collisions.

-Vesa Karvonen