[MLton] cvs commit: mlb integration

[Matthew Fluet]

> > That leaves: deadCode, allow{Import,Export}.  I can see arguments
> > both for and against making these normal annotations.  I guess I
> > don't see any harm in making allow{Import,Export} to be normal
> > annotations -- one can then ensure that the compiled code is "pure"
> > Standard ML.
>
> Agreed.  allowImport and allowExport should be normal (and I still
> wouldn't mind their defaults becoming false :-).

Sounds fine.  We might consider making their defaults true when compiling
a single .sml file, or providing a command line option to set the default.

> I lean toward making deadCode expert, simply because it's a new feature
> and hence we don't need to expose it.  Also, it can change semantics
> pretty severely.

Agreed.

> My only strong requirement is to support bootstrapping with the last
> public release.

O.k.  Then that works with the .cm we still have around.

> >  - what other mlb tools should we write:
> >    - mlbcat -- like cmcat, you get a list of files, losing all scoping
>
> Sounds trivial.  In fact, that's what I would expect the behavior of
> "mlton -stop f" to be when the input file is an mlb.

Maybe.  The Basis library is always a tricky thing -- do you really want
to pull-in all of those files.

> >    - mlb2pld -- mlb to Portable Library Description
> >    - pld2mlb -- the reverse
>
> All sounds good, but I'd rather spend my time improving the aspects of
> MLton that make it necessary to use SML/NJ. :-)  Hence, I'd argue to
> wait until we get a little demand for these, and to prioritize pld2mlb
> higher.

Agreed.

> Although, one advantage to having these, if they truly work, is that
> we could use them for self compiling, and hence develop purely with
> mlbs.  But I imagine there will be a lot of time-wasting gotchas in
> writing these.

Yes, and they aren't complete solutions.  Because cm2pld will still leave
.cm files in the imports, and likewise with mlb2pld.  So, you still need
to fiddle with file extensions, etc.