[MLton] mlb support
Wed, 21 Jul 2004 14:13:35 -0400 (EDT)
> Does allowConstant control _build_const, _const, or both? I guess
> both, and there's no reason to distinguish.
It controls both _build_const and _const.
> I wonder if "rebindEquals" should be called "allowRebindEquals" for
> consistency. It is a bit verbose, though.
It is easy enough to go with "allowRebindEquals"; it's only being used in
a few places.
> We could make false the default for allowExport and allowImport. That
> way people have to be explicit when they want to step outside the
> language. Although this would conflict with what we currently do, and
> maybe the leading "_" is enough.
I picked defaults that were consistent with what we currently
allow/intend. (Technically, we currently allow _overload and _prim in
user code; but, we certainly don't mean for them to be used outside the
> I have no objection to getting rid of the distinction between the two
> controls, and makign the default value of the warnMatch annotation be
> the value of !Control.warnMatch (which is set on the command line).
> I'm wondering what's the plan for all the other libraries (like CML,
> OpenGL, ...) with the packaged version of MLton. If libraries live in
> /usr/lib/mlton/sml/, which is where basis-library/ lives, why not use
> a single variable for both the basis library and for other libraries?
> Then, we can move the basis mlbs to the top of the basis-library
> directory, and reference them as
That's a bit verbose for my tastes.
> Or, we could even change the name "basis-library" to "basis", since
> the library part is redundant.
That is a little bit better. Although, I would choose $(SML_LIB) over
$(LIB). I've set things up so that $(VAR) is interpreted by
OS.Process.getEnv, and LIB seems like a likely candidate to already be in
> One thing I'm not sure I like is the redundant mlb file name.
I don't have a problem with it. I think conventions like lib.mlb and
sources.mlb obscure things.
> > 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.
> I'm not completely clear on why you can't still cache the elaboration
> of the basis and then check for its use. Is it the desire not to
> hardwire a constant or two? Or is it the desire to get the
> annotations (like sequenceUnit) that aren't covered by the basis mlbs?
Actually, it's neither of these things. Both the MLB parser and the MLB
elaborator want to cache .mlb files. I just haven't set things up so that
you can run the parser and the elaborator with a cache and get an updated
cache back at the end. Also there is the minor issue of identifying .mlb
files by inode.
> Since the SML/NJ-exported version of MLton is just a hack for testing,
> it's worth it to me to compromise a little to get back some speed.
> IIRC, we're talking 10-20s per compile.
YMMV. On my home machine, an SML/NJ-exported version of MLton takes about
6minutes to elaborate the basis-library. So, I've been just as happy
without the basis being processed at export, because I get a compiler
faster, which is sufficient for little tests on .mlbs that don't pull in
the basis. When I want to do a serious test, I recompile with MLton.
But, I think that threading the cache's through should be easy enough.