[MLton] MLB path variables and path maps
Tue, 23 Aug 2005 11:32:28 +0300
Quoting Stephen Weeks <firstname.lastname@example.org>:
> 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
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:
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