[MLton] the next public release

[Matthew Fluet]

Here are a few other thoughts for the next public release.

I've been thinking for a while that the User's Guide and/or the website
should have a "MLton Philosophy" section.  For example, I don't see
anywhere in the documentation a statement along the lines of "(Strict)
adherence to the Definition of Standard ML is a driving principle in the
development of MLton."  To some extent, this is mentioned in the
description of the type-checker.  Also, I feel like such a statement
partly justifies adopting MLBs over an existing system, because MLBs are
(formally) defined in the language of the Definition.

It would also be helpful to clarify the fine line we seem to walk in
relation to other SML compilers (SML/NJ in particular).  For example, we
would like to support NLFFI, but we (seem to) adamantly oppose or-patterns
and vector literals.  We have non-trivial language extentions (threads,
signals, weak pointers, finalizers, etc.), but they are "o.k." because
they live in the MLton structure.

There is also the GPL/open-source philosophy.  For example, I figure it
wouldn't take too much effort to support a few of the "syntactic"
extensions of SML/NJ: functor/signature within local, or-patterns, etc.
And, to be honest, I think it would be a great incentive for someone
wanting to port a bunch of SML/NJ code (especially any code already living
in SML/NJ).  But, it's also fairly clear that such a patch would be
rejected.  Now, nothing prevents anyone from writing such a patch, and
making it available through other means, but the "nice" thing to do would
be to warn them off up-front.

> * MLB files
> * New libraries: CML

I wonder how useful to end-users it would be if we gave hints for using
the SML/NJ library.  I don't think it is "fair" to deliver a whole pile of
SML/NJ library code with MLton (even though I know their license allows
it).  What might be useful, though, is to provide a .tgz that could be
unzipped in smlnj/src/smlnj-lib (which is provided by the default SML/NJ
installation) that would provide a bunch of .mlb files.  It may further be
useful to distribute the diffs that eliminate the SML/NJ-isms so that the
library is useful with MLton.  (Note: there really aren't that many; and
there will be even less when SML/NJ brings their Substring implementation
up to date with the spec; Substring.all was dropped a year ago.)

Also, looking forward to future libraries, I'm wondering if SML_LIB is the
best name for the root, and where should it be initialized.  Right now,
it's set in the mlton script.  Should we provide a convenient way for
users to add additional environment variables, without polluting their
process environement?; for example, we could read in a $(HOME)/.mlton-env
file with user specific environment/path pairs.  We could also provide a
global mlton-env that sets SML_LIB (and others).  I'd like to add
  SMLNJ_LIB_ROOT $(HOME)/smlnj/src/smlnj-lib
  SMLNJ_LIB $(SMLNJ_LIB_ROOT)/Util/smlnj-lib.mlb
  PP_LIB $(SMLNJ_LIB_ROOT)/PP/pp-lib.mlb
  ...
to my .mlton-env, and that's what I would suggest in the "hints" above.

Alternatives to SML_LIB might be:
  MLTON_LIB -- although that may conflict with a future library
  MLTON_ROOT
  MLTON_HOME
For some reason, I like getting MLton in there.