[MLton] release and future devel

[Matthew Fluet]

I'd like to push out a mlton release this summer, probably within the next 
three or four weeks, unless someone identifies a significant issue. 
Although there are few features added since the last release (20070826), 
there have been a number of bugs fixed.  Furthermore, it would good to 
make a release at this time before undertaking more significant 
developments.

I know of only three outstanding reported (but unverified) bugs:
    http://mlton.org/pipermail/mlton-user/2008-March/001358.html (Intel)
    http://mlton.org/pipermail/mlton/2008-September/030355.html (PolySpace)
    http://mlton.org/pipermail/mlton/2009-February/030513.html (PolySpace)
In each case, the company won't release source code to verify and diagnose 
the bug.

I have begun updating the doc/changelog file with a summary (and included 
some additional changelog entries), based on reviewing the commit 
messages.  Let me know if there are any other significant points.

I regularly self-compile on x86-darwin and amd64-linux, so I don't think 
that there are any issues on those platforms.  I should also be able to 
check x86-cygwin and x86-linux.  If you regularly use another platform, it 
would be helpful to verify that things work as expected on that platform; 
bootstrapping from mlton-20070826 and running the regression suite is a 
good baseline test.  Obviously, your favorite SML application is another 
good test.

Another reason for releasing at this time is that I would like to 
undertake a round of slash-and-burn to clear away some outdated and 
un-maintained code and to simplify some other aspects.  [I will be 
starting a new faculty position at the Rochester Institute of Technology 
in the fall.  I will primarily be working with undergraduate and masters 
students, and to make MLton an effective platform for research with such 
students, it needs to be simplified.]  This will include dropping some 
previously supported "features" and will likely be destabilizing in the 
short term (particularly for some of the more exotic platforms).

"Features" that I would like to drop:

   * Bytecode codegen --- the bytecode codegen has never gotten any
     significant use; it is not "portable" bytecode (which has confused some
     people); it is not well understood by any of the active developers.

   * Support for .cm files --- the ML Basis system provides much better
     infrastructure for "programming in the very large" than our rudimentary
     support for CM; in particular, we treat .cm files as simple list of
     files (recursively expanding .cm files unless we've seen them before),
     with none of the scoping that CM and MLB provide.  The cm2mlb tool can
     be used to convert CM projects to MLB projects, preserving the CM
     scoping.

   * time-label profiling --- this is only supported on the x86 and amd64
     codegens.  Using assembly labels for code coverage has been a bit
     awkward; there were the hard to implement getText{Start,End} functions
     (which Wesley eliminated in favor of binary search tree of just the
     profiling labels), it can be confusing as to whether other platforms
     support time profiling (using the C codegen and time-field profiling,
     they all should), and it complicates the native codegens that must
     introduce (and maintain) profiling labels for every basic block, which
     is a barrier to future codegens.  In any case, I don't think the
     time-field technique has a prohibitive cost (and what cost it has could
     be lowered):
       http://mlton.org/pipermail/mlton-commit/2005-November/000238.html

I'll mention the deprecation of the bytecode codegen and support for .cm 
files in the release summary notes; the elimination of the time-label 
profiling won't be a visible change in functionality.