[MLton] mlton-lib documentation

[Stephen Weeks]

> I've been playing around with the ML-Doc tools.  See
> http://www.cs.cornell.edu/People/fluet/MLtonLib
> for some preliminary documentation, just to get a feel for it.  

Looks great!

I hope to make libraries a major focus for the MLton release after
this one.  This includes: support for mlb files, file-based dead-code
elimination in the elaborator, making available some useful libraries
(DirectedGraph, Hash, Regexp, URL, ... <your request here>), and
documentation.

One thing I've started thinking about is how to make stuff available
from lib/mlton as well as the MLton structure of our current basis.  I
think it would be confusing for users to have these two different
libraries to choose from.  I further think that lib/mlton is way too
big, both in the number of things exported, and the sizes of some of
the signatures.  So, my current thinking as to the way to go is to
release a combination of what's currently in the MLton structure with
a subset of lib/mlton.

Another difficult issue is how separately library development should
proceed from MLton development.  One potential problem with letting
them go separately is that because the MLton compiler depends so much
on the library, it will become difficult to compile MLton with other
versions of itself.  That would be very bad.  Another solution might
be to have some stubs to make different library versions look similar,
like what we do now with the basis and with SML/NJ.  But keeping all
those stubs would be messy, error prone, and a lot of work.  So my
current thinking is that we should keep development of the MLton
compiler, the MLton structure, and the MLton library in close
synchronization.

Another problem is how to obtain maximum portability between different
versions of MLton and with other SML compilers.  Henry's ever-present
goal of being able to produce a standalone program that only uses the
basis library is reasonable to keep in mind.  However, once anything
uses the MLton structure this becomes difficult.  That is one
important difference between lib/mlton and the MLton structure -- the
former tends to be more portable.

Anyways, these are some thoughts.  More questions than answers for
now.

One effect for now though is that I think it is not worth documenting
all of lib/mlton.  Rather, it is worth spending time to pick out which
modules we want and which functions we want to export.  I think we
should err on the side of fewer modules and smaller signatures to
start.