[MLton] MLB path variables and path maps

[Vesa Karvonen]

Quoting Stephen Weeks <sweeks@sweeks.com>:
> 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'm not sure that version number information is the kind of information
that should be put into MLB files. At any rate, I think that it is
important to have a system that allows you to say things explicitly and
precisely. More elaborate systems can be built on top of such a system
(e.g. generate the config MLB file (substituting specific paths) based on
package dependencies).

I don't see how the current system would offer better support in this
respect. As far as I can see, the current handling of path variables is
too simple as basis to erect a package system upon.

Regarding the version number information, if we really want to put it
in the MLB files, then why not do something like this:

  config.mlb:
    var SML_LIB = `ml-find-pkg sml-lib date >= 2002`
    var SML_NJ = `ml-find-pkg sml/nj-lib version = 110.55`
    ...

In other words, path variables could be bound to computed values. (The
above syntax is only meant to give the idea that the paths are computed.)

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

Could you elaborate your thoughts on packaging systems. How does your
idea of a package system differ from the existing package systems (e.g.
Debian, Red Hat)? Would SML libraries ultimately be installed through
the existing package systems or would we need a completely new system
for them?

-Vesa Karvonen