[MLton] release and future devel
Matthew Fluet
fluet at tti-c.org
Thu Jun 11 13:59:30 PDT 2009
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.
More information about the MLton
mailing list