[MLton] mlnlffigen is awesome (was: bootstrap problem)

[Matthew Fluet]

> On Aug 19, 2005, at 12:09 AM, Stephen Weeks wrote:
> >> Another alternative would be to drop the implicit
> >> ~/.mlton/mlb-path-map and only have the flag to include a file map.
> >> A convenient convention is to have ~/.mlton/mlb-path-map and when
> >> you want to use it, you point the flag there.
> >
> > I'm OK with this.  There is clearly no loss in power or difficulty
> > upgrading since current calls to MLton can be emulated with
> > -mlb-path-map $(HOME)/.mlton/mlb-path-map.
> 
> What is so terrible about a per-user config file?
> It seems quite convenient to me...

It is convenient, for individuals.  As soon as you are working on a common 
code base, you need to ensure that everyone sets up their own config file 
the same, or use some sort of hackerly like Henry suggested.

> I don't see how using only one variable solves the name conflict
> problem either; the two projects will be subdirectories in the same
> place. 

Absolutely.  There is no general solution to this.  However, I think that 
directories allow you to impose/expose a hierarchy, whereas the whole 
point of MLB path variables is to hide the details.  Consider the 
following:

1) $(SML_LIB)/smlnj-lib/HTML/html-lib.mlb
2) $(SMLNJ_LIB)/HTML/html-lib.mlb
3) $(SMLNJ_HTML_LIB)/html-lib.mlb
4) $(HTML_LIB)/html-lib.mlb
5) $(HTML_LIB)

There is no denying the fact that things get shorter and arguably more
convenient down the list.  But, with 4) and 5), who are we (as the
distributer) to "bless" the SML/NJ Library's HTML library as _the_ HTML
library.  Certainly, any individual may decide that that is the HTML 
library they wish to use, so they should have the means to make it more 
convenient with their project.  But, they should also have the means to 
send their project out into the world with build instructions that don't 
require others to modify their configurations.

I admit that the distinctions between 1), 2), and 3) aren't as clear cut.  
But, at least 1) makes it very clear that you are decending into the 
SML/NJ Lib and the HTML sub-Lib.

> It seems very helpful to be able to install (as non-root)
> packages into one's home directory without having to worry about
> editing the basis file for dependent programs.

Absolutely.  

If you don't plan on releasing the code, then either a personal 
mlb-path-map or a per-project mlb-path-map works fine.

If you do plan on releasing the code, then a per-project mlb-path-map is 
the right way to go, because then your BUILD instructions tell the user to 
"edit the mlb-path-map to suit your setup".

> What am I missing?

I don't think you are missing much, just whether one's point of view is as
an individual developer, or as a group developer, or as a distributor.

Also, you can always set up a wrapper script to pass common options to 
mlton:

~/bin/mymlton:

#!/usr/bin/env bash

rargs=""
case "$1" in
@MLton)
        shift
        while [ "$#" -gt 0 -a "$1" != "--" ]; do
                rargs="$rargs $1"
                shift
        done
        if [ "$#" -gt 0 -a "$1" == "--" ]; then
                shift
        else    
                echo '@MLton missing --'
                exit 1
        fi
        ;;
esac

mlton @MLton $rargs -- \
	-mlb-path-map $HOME/.mlton/mlb-path-map \
	-default-ann 'allowFFI true' \
	"$@"