[MLton] upcoming release

[Matthew Fluet]

> It has been quite a while since our last release, so I would like to
> do a new one.  There aren't any huge new features, but we have
> accumulated a number of bugfixes, as well as some small improvements:
> 
>  * better exception history
>  * libraries: Int1, MLton.CallStack, MLton.Process.create, Word1
>  * FFI improvements: support for symbols

Some other small improvments:
 * better inclusion/exclusion of code for profiling
 * warnExnMatch annotation
 * updates of mllex and mlyacc (from SML/NJ)


There is also preliminary support for MLNLFFI, including a MLton specific
mlnlffigen program.  I know that it does not work correctly on C-code with
functions accepting or returning structs/unions.  (See the discussion
starting at http://mlton.org/pipermail/mlton/2005-January/026653.html )  
Though, it is able to access fields of structs/unions.

Also, I haven't tested it on any platforms other than x86-Linux, though I 
don't see any difficulties with other platforms.  Currently, I believe 
that all of our platforms agree on sizes for the basic C-types, though 
some do have different alignment requirements for > 64-bit values.  To 
that end, I think the right way of factoring those dependencies is with 
compiler set MLB path variables; see
http://mlton.org/pipermail/mlton/2005-July/027421.html

I'm not pushing for these issues to be resolved before the release, but
it's just an update on a pile of code sitting in the repository.  NLFFI
received only mediocre support in the 2005 Survey, and I'm happy enough to
let it go as is.  If there are users out there who want/need better
support, we can grease them when they squeak.  The question is whether or
not to incorporate it into tools/libraries targets of the top-level
Makefile and include them in a binary release.

> There is also a big improvement on the licensing front, as MLton will
> now be released under a BSD-ish license instead of the GPL.  That
> alone is worth a new release in my opinion.

Agreed.  Better to release soon with the new license and less features.

> I didn't try out MinGW, but I'd be happy for someone to give it a
> try.  As I recall, we're still in the state where there is some
> strangeness in saving the world due to 

Due to what?  Not that I have a MinGW platform around to try it on.

> The biggest open question in my mind for the release is what to do
> about documentation.  This will be our first release post wiki.  It
> probably makes sense to include a snapshot of (some fragment of) the
> web site to include with each package in html format.  I would like
> input on the following:
> 
>  * should we have other formats besides HTML?  If so, what, and how
>    should we obtain it?
>  * should we include the whole website or a fragment?  What fragment?

I presume we are still including the man pages, which should be 
coordinated with the wiki pages.

I suspect the whole website (excluding the obvious links to Download 
attachments and CVS/SVN/mail archives) isn't all that big, even in HTML 
format.  What I would find more annoying is the wikiness of the HTML 
found in /usr/share/mlton/doc.  I'd vote to post-process the HTML to 
eliminate the wiki action links, though I don't know how hard that will 
be.