[MLton] mlb support

Matthew Fluet fluet@cs.cornell.edu
Tue, 20 Jul 2004 18:59:27 -0400 (EDT)

I've got mlbs working to the point where pretty much everything except for
the def-use controls is working.  Currently, the annotation language looks

ann := allowConstant {true|false}   defaults to false
     | allowExport {true|false}     defaults to true
     | allowImport {true|false}     defaults to true
     | allowOverload {true|false}   defaults to false
     | allowPrim {true|false}       defaults to false
     | deadCode {true|false}        defaults to false
     | rebindEquals {true|false}    defaults to false
     | sequenceUnit {true|false}    defaults to !Control.sequenceUnit
     | warnMatch {true|false}       defaults to
                                     orelse !Control.warnRedundant)

The defaults are reset for each .mlb file.

Is there a reason that warnMatch is split into the two controls?
I haven't gotten rid of the !Control.warnNonExhaustive or
!Control.warnRedundant predicates in defunctorize.fun.  This means that
even if you annotate with  warnMatch true  , you won't get the warnings
unless you compile with -warnMatch true.  That kind of goes against what
we wanted, but if I drop the predicates, then the only use of those
controls will be to default the warnMatch annotation, and I can't see
keeping two of them around for that purpose.

I think I've simplified the handling of -build-constants.  Rather than
sucking in the entire Basis Library, -build-constants just elaborates
whose contents look like:


    allowConstant true,
    allowPrim true,
    rebindEquals true,
    deadCode true

Then, build.mlb looks like
  ann  deadCode true  in
and it makes it clear that no other extensions are needed for the
remainder of the Basis Library.  (Another use of rebindEquals and
a use of allowOverload are needed in basis-2002.mlb.)

Right now "$(SML_BASIS)/libs/primitive.mlb" is hard-wired into the
compiler.  I guess it's no worse than basis-library/libs/build having been
hard-wired in before.

One question is where to make SML_BASIS actually point.  Recall that the
directory structure for the basis-library looks like:


That was fine for before, but I don't want to write:

I'd rather write:

so I'm thinking of pointing SML_BASIS to basis-library/libs.

As a consequence of this rearrangement, the SML/NJ compiled version of
MLton doesn't pull in the Basis Library.  Means that things will be a
little slower, but they were going to be anyways, because expanding a
single z.sml file to
  local $(SML_BASIS)/basis-2002.mlb in z.sml end
meant sucking in the basis at compile time.

Those are the major points.  I'm still trying to figure out how best to
handle the def-use information.  I at least want a coherent story for
dealing with warnUnused, because it is fairly useful.