[MLton] Welcome to Clark C. Evans

[Stephen Weeks]

Welcome to Clark C. Evans, who has joined the MLton mailing list.
Clark is the CTO at Prometheus Research (www.prometheusresearch.com),
and writes:

> I used SML about a decade ago, but have been doing commercial
> programming since then (and am now thinking about going back for a
> PhD).  So, I was considering doing my next project in SML to get my
> feet wet again.

He also asked the following questions, which I answer below.

> To be 'fiesable', I'm concerned about three things:

>   - ability to generate libraries callable from C
>     (wrappable by SWIG, etc.) so that my customers
>     can use them from Python, Ruby, Perl, etc.

MLton doesn't support this right now, but I don't think it's very
hard, since we do have an FFI that lets us call from SML to C and C to
SML.  The work to be done is in unbundling our assumption, used in
various places, that MLton is generating the "main" program.

>   - are continuations useable?  I'm writing a 
>     parser, validator, and simple functional transform 
>     language, and I've found continuations to be very 
>     helpful; I saw that they were "not efficient" on the 
>     mailing list, is this true?  Anyway to fix this?

Since call/cc and throw in MLton take time proportional to the size of
the stack, the usability of continuations depends on how often you
create and call them relative to other work done by the program and on
how large the stack is.  MLton does have threads, however, which can
be used as "one-shot" continuations, with a constant time throw
(thread switch).

As to improving the performance of continuations, I'm not sure.  I'm
familiar with the stuff done in Scheme implementations and with the
choice made by implementations like SML/NJ to allocate all stack
frames on the heap.  I'm not sure if the performance impact of any of
those approaches is worth the benefit of having faster continuations.

>   - ability to let commercial vendors use the library
>     without licensing concerns; this means that the
>     resulting code has to be, LGPL (library GPL) or
>     equivalent;

Unfortunately, this is not feasible with MLton right now.  The
original work on MLton was done at NEC, who holds the copyright, and
was released under the GPL.  Because executables generated by MLton
are derivative works of MLton (due to containing library code and the
runtime), they must also be licensed under the GPL if they are
distributed.  We have had discussions with NEC to try to get them to
re-release under a BSDish license, but so far without success.  If we
do succeed, we plan to move to a dual licensing scheme, continuing
with the GPL and some other (possibly for fee) license for commercial
users.

>     a sub-concern is that
>     could it be possible to generate win32 without
>     cygwin if one doesn't need posix/unix functions?
>     (I don't need POSIX and Cygwin is GPL)

This should be possible, but will take some work.  At various points,
some people on this list have talked about using MinGW, but I haven't
had time to look into it myself.

> The project itself is a YAML parser (http://yaml.org)
> in particular, one with native ML data type bindings.
> YAML already has a Ruby, Perl, and workable Python
> implementation via the syck "C" library. If we cannot 
> work out the licensing issue, I will be proceeding with 
> a "C" implementation... (found a neat continuation hack
> about a month ago) but I'd really like to use ML 
> for this project; I'd like to start using ML in more
> commercial code (which is now a mixture of C and Python).

We'd like to see you use MLton/SML too, especially for commercial
stuff, but given your questions above, sadly my answers don't seem to
quite line up :-(.