[MLton] mlb support

[Stephen Weeks]

> I don't agree that dead code should be lumped in with the other def-use
> info.  Dead code is a completely separate pass, uses an entirely different
> notion of "use", and can very easily be extended to handle arbitrary
> interleaving of lib and user code.

Ahh.  It hadn't occurred to me how easy it was to generalize the
deadCode pass.  But you're right.  And given that, I agree, there is
no need to use (the very coarse) split for dead code.

> >   4. The basis library sets some essential hooks that the compiler
> >      internals depend on.
...
> In the not-so-long run, I think it would make sense to factor as much of
> this as possible out of the Basis Library into it's own Critical Library.

Sounds reasonable.

> I was thinking:
> 
> <bdec> ::= !(<annlistP>) <abdec>
>          | <abdec>
> 
> <abdec> ::= local <bdec> in <bdec> end
>           | basis <bid> = bas <bexp> end
>           | ...
> 
> <annlistP> ::= ann
>              | ann COMMA annlist
> 
> <annlist> ::=
>             | ann COMMA annlist
> 
> <ann> ::= ...

The reason I put the parens around the basis dec is because I wanted
to make it clear what the scope of the annotation was (this is not
obvious since we use juxtaposition for sequencing).  BTW, I didn't
understand the thinking behind "!", as opposed to some other keyword
(like "ann").  How about

<bdec> ::= ann <annlist> in <bdec> end
         | basis <bid> = <bexp>
         | local <bdec> in <bdec> end
	 | open <bid>*
         | <bdec> <bdec>
         | <empty>

<annlist> ::=
            | ann COMMA annlist

<ann> ::= ...


As to the annotations, I think that if we're going to be treating
things like fluid lets, then it is best to directly express the
assignment in the annotation.  Something like

<ann> ::= allowConst {false|true}
        | rebindEquals {false|true}


Your points about the weak expressiveness of my splitting proposal are
well taken.  It does seem too brittle.  How about the following
approach?  Make an analogue of each of the flags as an annotation:

<ann> ::= showBasis <file>
        | showBasisUsed <file>
        | showDefUse <file>
        | warnUnused

The idea is that "ann showBasis foo in bdec end" causes the basis
to which bdec evaluates to be written to file foo.

Similarly, "ann showBasisUsed foo in bdec end" causes the portion of
the basis to which bdec evaluates that is used anywhere else in the
program to be written to file foo.

So, showBasis and showBasisUsed both display information about the
basis 

On the other hand, showDefUse and warnUnused both behave like fluid
lets, in that they cause the elaborator to enter a state where it
keeps track of the variables defined in the scope of the fluid let.
Then, when elaboration of the program finishes, "ann showDefUse foo in
bdec end" causes the variables defined in the (elaborator dynamic)
scope of the the "ann" to have their use information written to foo.
Similarly, warnUnused causes the variables defined in the scope of the
"ann" that are not used anywhere else in the program to display a
warning message.

For backwards compatibility, I think it should be reasonable to come
up with a way that the command-line flags cause the appropriate
annotation to be inserted into the default mlb files that get
generated for .sml and .cm files, as well as for no file.

There is a little bit of orthogonality in the annotations that isn't
expressed as nicely as I'd like.  For example, both showDefUse and
warnUnused cause variable definitions to be recorded.  And, there is
no way to turn that off.  Perhaps there should be a separate
annotation that controls this.

<ann> ::= keepDefs {false|true}

Anyway, I'm not wedded to any of the details, but perhaps this is a
reasonable approach to pursue?


> > To make splitting available for more than just the basis library, we
> > need to add the flags we discussed before: -{load,save}-basis.
> 
> What precisely is a .basis file?  A saved world? 

That was my intended first-cut implementation.  But given your points,
I think this is a separable issue (although the flags still seem
useful).


> I don't think I saw anything wrong.  In any case, I've TeX-ed up the
> syntax & semantics of MLBs in the style of the Definition.  I'm planning
> on including it as an appendix to the user's manual, with a less technical
> presentation of how to use mlbs in the manual proper.

Excellent.