[MLton] SML documentation tool(s)

[Ray Racine]

On Sun, 2005-06-19 at 21:27 +0200, Jesper Louis Andersen wrote:

> I agree with this statement. The problem of Standard ML in general is 
> not that the language is hard to learn, not that it is not used widely 
> enough, not even that its type system is too restrictive and the 
> language is too simple. The problem currently is solely the lack of 
> standard library facilities.

Is this the cause or the effect?  A popular language will have
libraries, an unpopular one will not.  I'm not sure the SML of 10 years
ago will compete with some of the evolving languages we have today.

On the other hand all in all I like SML.

On the library issue.  Even a trivial application of today requires
massive libraries to compile the equivalent of a hello world.  Take a
simple web application for example may include.

	- HTTP protocol library.
	- RDB driver.
	- XML parser.
	- XML binding / code generating utility.
	- Transaction Mgr.
	- Resource pooling code.
	- Template HTML/XML generation system.
	- Security routines.
	- Logging routines.
	- True native SMP capability libraries.
	- SOAP libraries.
	- SML code generation utility from WSDL.
	- Dynamic code loading.
	- High Availability.
	- Session support libraries.
	- yada yada yada.


A modern, yet modest "web" application requires a rather extensive
support environment of libraries.  Easily over 100K worth of library
code to support a modest 10K LOC application.

In the MLton world this is a problem.  The strength of MLton is whole
program compilation.  The weakness of MLton is whole program
compilation.  Whole program compilation and libraries are antipodes.

Even the combination of SML/NJ with MLton, even assuming they were
merged to appear to the user as a seamless system, one for incremental
development and the other for the finished product appears to be
problematic.  

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.

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.  I also
thought this HLF language must accommodate objects.   Something along
the lines of where Scala is going.  But I'm not sure now.

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

Ray