[MLton] MLton in the future
sims at reactive-systems.com
Mon Jan 24 19:38:21 PST 2011
On Mon, Jan 24, 2011 at 10:06 AM, Magnus Rattfeldt <magnus at rattfeldt.se>
I am considering choosing SML and MLton for a new side project where I
> will build a framework for local search optimisation algorithms. I
> have previously written such a framework in OCaml during my PhD
> studies. Now that I am going to more or less reimplement everything,
> it is a good opportunity for me to try out MLton and its whole-program
> optimisation philosophy.
I am glad you are considering MLton. I am not a developer, but I am a very
user of MLton. Your questions are certainly reasonable, so let me share
thoughts that might help mitigate your concerns.
I work for a small company (9 people) that develops testing and validation
for embedded applications. Most of our customers are in the automotive and
aerospace industries. Our main product is implemented in SML and we
use MLton. We have used SML here since the start of the company in 1999 and
MLton for the past several years. We currently have a code base of several
thousand lines of SML code.
There are a number of other companies who use MLton in successful
products as well as dozens of very large applications developed
and research labs. Some of these are listed here:
However, when I look at the (latest) MLton release cycles and the
> mailing lists it seems to me that the MLton development is not very
> active anymore (3 years between the two latest releases, rather low
> svn activity, not a very active user/developer list). So I am a bit
> concerned of choosing MLton due to this.
While these could be taken as indicators of a declining project, I believe
they are more
due to the fact that MLton is a mature tool that is extremely stable. In
with a large code base originally developed under a different compiler, we
only a handful of issues in MLton all of which have now been addressed.
In addition to being robust, we have also found MLton to produce
extremely efficient executables, both in terms of speed an memory usage.
So since MLton works well there is not a huge need for super frequent
a perfect world, less than 3 years might be nice; but, in my mind fewer
are rock solid are preferable.
As for traffic on the mailing lists, admittedly, it is not huge. But as I
look back over the
past couple of years, there is at least some traffic every month. Pretty
much any issue
raised gets a quick response. Some responses are quite in depth discussions
> As performance will be essential for my application, falling back on
another (of the current ones) SML implementation in the future is not
While I think it highly unlikely that there would be an obstacle blocking
of MLton, having other world class compilers to "fall back" on is not a bad
to have. One nice benefit this gives you is an easy way to test the
We compile our application with both MLton and SML/NJ and compare the
results against each other.
So I would like to ask here if my concerns are justified? Or can I
> choose MLton and be confident that its development will continue,
> possible bugs be fixed, and perhaps even that new features and
> optimisations will be implemented?
Having used OCaml, you already know the benefits of the ML family. I think
you will not be disappointed if you give MLton a try. It has certainly
Chief Executive Officer - Reactive Systems, Inc.
Email: sims at reactive-systems.com
Phone: (+1) 919-324-3507 ext 101
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the MLton