[MLton] SML documentation tool(s)

[Stephen Weeks]

> Whole program compilation and libraries are antipodes.

This is not true, as long as one is willing to distribute source for
libraries.

> Witness the issues the MLton core team has with current compiler
> development.  Even bringing to bear judicious application of SML/NJ and
> MLton is pushing the envelope of efficient development of a 150K LOC
> application.

I don't feel like we're anywhere near the limit.  And I don't feel
like my development environment stands in my way all that much.  When
working on MLton or compiler stuff, I even usually already have the
libraries I need.  And when working on other stuff, the problem is
libraries, not development environment, by an order of magnitude or
more.

> If a functional language does find its way into the main stream, I
> believe it will be a "new" one which takes the best of SML + Haskell
> + Scheme/Lisp and somehow finds the magic mix to be special.

It seems contradictory to claim that a major weakness of the SML world
is libraries and then to claim that the way to fix the problem is to
design a new language.  To my eyes that just recreates the problem
(and makes it worse because there will be even fewer libraries in that
language).  If the problem is libraries then the fix is to work on
libraries (and documentation and packaging).

> I wander...  A library solution seems to me to entail some mechanism
> for separately compiled libraries.

Not at all, as long as one is willing to distribute source for
libraries.