[MLton] mlb support

> > With regards to caching the .mlb files for the basis and the like, I would
> > say that it is probably a bit scary too not re-lookup the inode number and
> > device on each run. I'm thinking that a copy (to another machine for
> > instance) will change them.
>> Certainly copying the basis on installation will change the inode number
> of files. That would suggest that we have a post-install operation to
> read in .mlbs and output a world with them parsed/elaborated.
I'm getting confused. I thought we were just talking about a hack to
speedup an SML/NJ-compiled MLton, which has no bearing on the binary
MLton packages that we distribute and hence no need for post-install
stuff. Why do we need to cache bases across runs of a MLton-compiled
MLton?
> Of course, there is a whole tricky mess of how to decide that a previously
> loaded .mlb corresponds to the file-name now under consideration. If you
> can't trust the inode from run to run, then you need to look things up by
> (absolute?) (real?) path name. But that begs the question of what to do
> if $(VAR) changes from one run to the next? And what if I change a .sml
> file referenced by a .mlb? When, and how do I find out that I need to
> rebuild the cache? Honestly, it just seems like a slipperly slope to CM's
> (confusing) notion of stable libraries.
I agree. For the first cut, I think it would be best to elaborate the
entire program for each run (the only caching being of mlbs within a
run).
> I think you spend the majority of your time looking at .sml files (where
> Foo.t is a win over Foo.foo) and a minority of your time looking at .mlb
> files.
Agreed.
> Again, it's a slippery slope from shortening names, to implicitly
> expanding
> $(SML_BASIS)/basis
> to
> $(SML_BASIS)/basis/{basis.mlb,sources.mlb,lib.mlb,t.mlb,m.mlb}
> and CM's (confusing) notion of anchors.
I don't really buy this slippery slope. We're just talking about a
convention, and we can decide not to do that expansion. And it
doesn't seem all that confusing either way. Anyways, I think this is
a very minor issue. For now, it seems best to have no support for
special conventions and to allow people to do what they want. Henry,
if you want to call your mlbs m.mlb, go for it.