[MLton-user] where to next?

[jlouis@mongers.org]

At Mon, 3 Jul 2006 15:59:33 -0700,
Stephen Weeks wrote:

>  * Support for multi-core.
>
>      This would give MLton something that OCaml doesn't have (and
>      Haskell does) and would be an attraction to early adopters
>      looking for effective ways to program such machines.

This is an interesting subject. Haskell of course does SMP by noting
"Since our language is pure, there is no danger in both CPUs
calculating the same computation and giving the result twice and
therefore we can avoid locking in many cases" (greatly
simplified). The relevant paper by Simon & Simon & Tim Harris is

http://www.haskell.org/~simonmar/papers/multiproc.pdf

How to attack multi processor support in MLton is not clear to me,
since SML is imperative at its core. But this only makes for a far
more interesting problem!

>  * Library infrastructure.
>
>      More libraries, better documentation for them, and an
>      internet-based infrastructure for community library development
>      and usage.

SML has adopted the same library philosophy of C: Let us give people a
tool for building libraries (MLBs is this tool for SML in my opinion)
and see what comes out of it. The problem with this philosophy and SML
is that nobody did provide libraries.

Perl has a library process known as CPAN, which goes to a long way to
help the user. It contains a dynamic environment for automatically
downloading and installing missing libraries (perl -mCPAN
...). Haskell built the Cabal system and has a community around cabal
packages letting people contribute. They have both specified a
hierachial library structure.

Another programming language in this category is Java, which shines at
program packaging, unique naming of identifiers, search paths for the
environment (in a machine independent way).

Scheme chose the SRFIs (srfi.schemers.org. I do not think this is the
way to go for SML, but for Scheme it works since it unifies various
almost compatible ways of doing things in various scheme
compilers/interpreters.

Personally, I think the SML library process should be based on MLB
files - but we need a way to package software in a uniform way. I know
this is equivalent to reinventing a package system of a major linux
distribution, but it seems to be what other people does. I would like
to see a clever solution to this problem.