[MLton] cvs commit: mlb integration

[Stephen Weeks]

> True.  The "normal" annotations certainly include: sequenceUnit,
> warnMatch, warnUnused, and forceUsed.  The "expert" annotations
> certainly include: allowConstant, allowOverload, allowPrim,
> allowRebindEquals.

Agreed.

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

> Yes, we need to duplicate the information, but that doesn't preclude
> making one derived from the other.  If we keep to fairly stylized .mlb or
> .cm files, we can probably textually convert one to the other. 

If you think it's worth figuring out how to do this, I have no
objection.  If not, I have no objection to duplicating info.

Another thought on how to do it would be to have a third format in
which we list the files once for each directory, and instantiate the
file list into a hand-written template for each system.

> That raises a couple of other issues:
>  - how far back in self-compiles do we support

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

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

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

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.