[MLton] Welcome to Bartlomiej Szymczak

Vesa Karvonen vesa.a.j.k at gmail.com
Mon May 21 00:24:21 PDT 2007


On 5/6/07, Stephen Weeks <sweeks at sweeks.com> wrote:
> Welcome to Bartlomiej Szymczak, who has joined the MLton list.
> Bartolomiej is an MSc student at the Technical University of Denmark.
[...]
> He has used SML in a number of classes and wants to help out with
> MLton development and see SML become a more popular language in
> industry (after finishing his thesis :-).

Well, I guess this comes a bit late, but as I've done a bit of SML selling
at one particular company, I have a few ideas on how to help SML become
more popular in the industry.  In this message, I'll elaborate on one of
them.

In our case there is a huge amount of legacy C code, both libraries and
applications, and a major concern is being able to take advantage of the
existing code.  While there are companies that don't have huge amounts of
proprietary code, being able to take advantage of existing third party
libraries, which often aren't written in SML, is just as important.  I
think that making it easier to write bindings to non-SML code would make
it easier to sell SML and MLton.

MLton currently provides a FFI (http://mlton.org/ForeignFunctionInterface)
that does make it possible to use existing C libraries.  In particular,
MLton's FFI supports callbacks (calling SML from C), which I consider a
vital feature.  However, MLton's FFI is rather primitive.  Hand written
bindings using MLton's FFI are type-unsafe (there is no verification that
imports/exports in SML code match with the C code) and easily broken when
code on the C side changes.  MLton also provides a higher-level FFI in the
form of ML-NLFFI (http://mlton.org/MLNLFFI).  Writing bindings using these
is certainly possible, but there are number of hurdles.

First of all, ML-NLFFI, in particular, is scantily documented.  Frankly,
Matthias Blume's paper on ML-NLFFI (http://mlton.org/References#Blume01)
is intellectually stimulating for someone interested in programming
languages (like me), but doesn't quite serve as a tutorial for someone who
just wants "to call the damn function".  A hands on tutorial, with plenty
of examples, for writing bindings to existing C libraries using ML-NLFFI
could help a lot.

If and when someone gets as far as actually trying to use ML-NLFFI, one
quickly runs into a big problem with ML-NLFFI.  The interface generator
(mlnlffigen) is unable to parse system headers and spits out bad error
messages.  One can work around this by tailoring headers for the
generator, but having to do so is quite annoying.  Improving the ML-NLFFI
generator to accept some common extensions (e.g. calling convention
specifiers, C99 extensions, pack pragmas) and providing a library binding
to the C standard library could make the experience much smoother and
reduce the need to use tailor made headers.

ML-NLFFI doesn't support calling from C to SML.  One has to use MLton's
primitive FFI to do that.  Library support and a tutorial for dealing with
callbacks would help. See the discussion starting from
http://mlton.org/pipermail/mlton/2007-February/029598.html .

No language should be an island.  One thing that could help would be to
have bindings to "scripting languages" such as Lua and Python (and other
languages designed for embedding).  SML, being a higher-order languages,
is much better suited to that than most mainstream languages, see
http://mlton.org/References#Ramsey03 and
http://mlton.org/References#Benton05 .  High-level bindings to other more
mainstream languages (e.g. Java) could also help.

-Vesa Karvonen



More information about the MLton mailing list