[MLton] mlb support

[Matthew Fluet]

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

Good point.

> BTW, I didn't
> understand the thinking behind "!", as opposed to some other keyword
> (like "ann").

"Historical" artifact: I first considered an annotation just for the dead
code pass.  In that situation, I was thinking of using ! for library code
and !! for user code, and just annotating a .mlb file.  As I thought about
using annotations for other aspects, I kept the notation.

But, a scoping keyword would be fine.

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

No argument.

> 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

I would kick showBasis out of this group.  It is not def-use related; in
particular, the basis defined by a particular bdec remains the same,
regardless of how the bdec is used.

Also, I'm not keen on the showX <file> annotations; seems weird to
produce these files just based on the annotations.

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

I'm not sure that this will work the way the notation would lead me to
believe that it works; for example:

z.mlb:

  local
    basis B = bas  basis-2002.mlb  end
    basis B1 = bas  ann showBasisUsed a1.basis-used in open B end  end
    basis B2 = bas  ann showBasisUsed a2.basis-used in open B end  end
  in
    local open B1 in a1.sml end
    local open B2 in a2.sml end
  end

I'd like to believe that this will write to a1.basis-used the portion of
the Basis Library used in a1.sml and write to a2.basis-used the portion of
the Basis Library used in a2.sml, but don't think that will happen with
the infrastructure we have.  I suspect that this will actually write
nothing to either of the files, because no new decs are introduced by the
annotations, despite the fact that new bindings are introduced.


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

It shedding some light on the possibilities.


Here are some other scenarios to consider.

Annotations as pragmas:
 - deadCode, rebindEquals, lookupConst
    + these definitely seem to fall in this category: compile this code
      specially
 - warning behavior for legacy code
    + suppose I have a pile of code from somewhere, that I want to use
      in a library.  I'm a principled programmer, so I always compile with
      -warn-match true & -sequence-unit true.  Unfortunately, the author
      of the other code wasn't so principled, and I'd love to be able to
      include their code in a mlb as follows:

      proj.mlb
         ann warnMatch false, sequenceUnit false in util.mlb end
         ann warnMatch true, sequenceUnit true in mycode.sml end

      Note, I wouldn't expect the warnMatch true and sequenceUnit true
      annotations to generate warnings if the appropriate options weren't
      set on the command line.  So, one probably wouldn't use such
      annotations unless they were buried under a corresponding false
      annotation.
    + I might also develop my code with -warn-unused true, but doing so
      leads to lots of errors from the old code.  Could we accomodate
      turning off the warning in the old code?

Maybe we ought to also send a mail to MLton-users and see if anyone has
used the def-use info, and what they think of it.  Personally, I like
warn-unused, although I think we'll need to consider how this interacts
with mlb projects.  I can see a use for show-basis when developing mlb
files; but, as I've said before, I think it's acceptable to only support
the case of displaying the final basis generated by the input program.
Otherwise, I don't think I've ever used -show-basis-used or -show-def-use.