[MLton] ML Workshop, sML Evolution, and CUFP trip report

[Stephen Weeks]

Last week I attended the following meetings affiliated with ICFP in
Portland.

  Sep 16  ML Workshop
  Sep 17  sML Evolution Meeting
  Sep 21  CUFP (Commercial Users of Functional Programming)

Here are some notes.

------------------------------------------------------------
ML Workshop
http://gallium.inria.fr/ml2006/program.html
------------------------------------------------------------

This was an all-day meeting attended by about 50 people.  I started
the day with a talk on whole-program compilation in MLton.  I've put
the slides on mlton.org.

  http://mlton.org/References#Weeks06

The talk seemed to be well received, with a number of questions during
and after the talk.  There was interest in whether or how MLton could
support features not currently in SML, e.g. polymorphic recursion, but
in other languages like OCaml and Haskell.  I was surprised at how
uncontroversial the idea of whole-program compilation was.  In fact,
that was an observation made by me and others throughout the whole of
ICFP and affiliated workshops.  Whole-program compilation in general,
and MLton in particular, have gained a lot of acceptance as a viable
way to go.  That's quite a change from, say, five years ago.

I got to meet Tom Murphy VII, a long time MLton user, who gave a
couple of nice talks on SML-related stuff going on at CMU.

  Grid ML Programming with ConCert
  http://mlton.org/References#Murphy06

   Describes a core-SML-like language for programming applications on
   a grid of computers.  The compiler for the language, Hemlock is
   "much like a standard (whole-program) compiler for a typed
   functional language".  Hemlock is implemented using MLton/SML.

  A Separate Compilation Extension to Standard ML
  http://mlton.org/References#SwaseyEtAl06

   Describes a language in the same category as CM or MLBs, layered on
   top of the SML module language, that is aimed at explicitly
   expressing the dependencies needed to enable separate compilation.
   The language seemed to be more verbose than MLBs, and I am unclear
   on whether one could express the same concepts within MLBs and
   achieve separate compilation there.

I liked Don Syme's talk on "Leveraging .NET Meta-Programming
Components in F#", mostly because the F# work really brings home the
point that there is a whole world of tools and libraries out there,
and that one hurts oneself by not integrating well with it.  I have no
idea how or if MLton should take advantage of that world though.

------------------------------------------------------------
sML Evolution Meeting
------------------------------------------------------------

This was an ad-hoc meeting arranged by Andrew Kennedy for the
afternoon after the ML workshop.  About 25 people attended.  The idea
was to bring together representatives of many of the SML
implementations to discuss sML (successor ML)

  http://successor-ml.org/

and how to evolve SML to get there.  Here were attendees affiliate
with various implementations.

  Hamlet: Andreas Rossberg
  MLton: Henry Cejtin, Matthew Fluet, Stephen Weeks
  Moscow ML: Claudio Russo
  SML.NET: Nick Benton, Andrew Kennedy, Claudio Russo
  TILT: Karl Crary, Derek Dreyer, Bob Harper

(apologies if I missed anyone)

Bob Harper spent a lot of the meeting espousing his work toward a
fully mechanized expression (in Twelf) of a new version of the
Definition of SML, modified in various ways and using the Harper-Stone
style.  This seems like a logical next step and a good direction for
the definition to go.  The idea is to use the new definition for
experimenting with new features, both small and large, e.g. type
classes

  http://mlton.org/References#Dreyer06

There was some discussion that Andreas Rossberg's Hamlet would be a
good testbed for new features, and it was mentioned that some of the
features discussed on successor-ml.org had already been implemented
there.

Dave MacQueen expressed his belief that we should strive for
simplicity of language design, and should not be hamstrung by
compatibility with old code.

There was some talk about removing "broken" features of the language
(polymorphic equality, structure sharing, ...).

I expressed my view that there are well over a million lines of extant
SML code, much of which compiles with MLton, which closely adheres to
the Definition, and that making small changes or removing old features
breaks that code without helping users.  I argued, perhaps not as well
as I could have, that the biggest bang for the buck is gained by
making making big changes/improvements and not breaking old programs.
I also pointed out that there are eight extant SML compilers and that
no one compiler can mandate change and hope that the others will
follow.

In the end, my conclusion was that there was not much consensus about
how to proceed, and that the different SML implementations have
different, somewhat incompatible, goals.  I think that things will
proceed much as they have been.

------------------------------------------------------------
ICFP
http://icfp06.cs.uchicago.edu/
------------------------------------------------------------

I did not attend ICFP (Sep 18-20), but I did pick up the paper
produced by the programming contest organizers: "The Cult of the Bound
Variable: The 9th Annual ICFP Programming Contest".  I couldn't find a
copy online, so if someone could send a link, that would be great.  I
was pleased to see that the contest organizers used MLton/SML to build
their Humlock compiler (presumably a modified version of Hemlock,
mentioned above) and to build their universal machine implementation,
UM.  They implemented the UM in a number of languages and have a
benchmark showing that the SML implementation is slower only than the
C and assembly implementations, and is significantly faster than many
other implementations.

The MLton UM implementation without bounds checks was 13% slower than
the C implementation, and the implementation with bounds checks was
67% slower.  That is an unusually large hit for bounds checks (almost
50%), more than I can remember seeing for any program.

-----------------------------------------------------------
CUFP (Commercial Users of Functional Programming)
http://www.galois.com/cufp/
------------------------------------------------------------

This was the third CUFP, and was a great success.  Attendance was
quite good -- 47 people registered and there were 57 people in the
room at peak.

There were talks about commercial uses of Erlang, Haskell, OCaml,
Scheme, and SML, as well as a couple of more specialized FP-inspired
languages used in hardware verification.  As an added bonus several of
the speakers ended their talks by mentioning that they were looking to
hire FPers.  There was some discussion about getting a combined web
page showing all the commercial FP activities as an enticement to
educators and students that studying FP is a useful task and can lead
to a good career.

The talk by Reactive Systems was the sole one on commercial use of
SML.  They have a 250k line system for testing of embedded systems
models written using Simulink/Stateflow.  I hope there will be another
one or two companies using SML that speak next year (AnswerMine,
PolySpace, SSH, ...).

------------------------------------------------------------
Other notes
------------------------------------------------------------

Andrew Kennedy of the SML.NET compiler group updated me on what's
going on there.  He's working on changing all of the SML.NET compiler
ILs to be mutable in the hope to improve compiler performance, similar
to what they saw with Sam Lindley's experiments

  http://mlton.org/References#BentonEtAl04_2

I expressed skepticism at the tradeoff involved -- possible
compile-time speedup vs hellacious bugs from using a mutable IL -- but
it will be interesting to see the results of the experiment.

Tom Murphy mentioned that TILT is able to self compile, which I did
not know.  It takes hours, but is still a good sign of robustness.

Several people expressed interest in using MLton for language
research.  I am quite open to this now that we have MLB annotations --
it is easy to imagine adding language extensions and having them
enabled by annotations while maintaining a stable language for users
who need it.

 * Umut Acar is interested in extensions to express certain properties
   of self-adjusting computation that can not be expressed with the
   current type system.
 * Karl Crary is interested in modifying MLton to do certifying
   compilation. 
 * Derek Dreyer is interested implementing his work on type classes.

I talked with some of the SML/NJ team (Matthias Blume, John Reppy) and
it looks like SML/NJ development is picking up again after a several
year lull, in part at least due to an NSF infrastructure grant that
has given them the ability to hire some grad students.  John said that
there was progress on getting his new runtime into SML/NJ and on
improving MLRISC to get an x86-64 codegen.  John also mentioned that
he has his own OpenGL binding for MLton that he has been using for
teaching graphics.  He said he would be willing to put it in our
repository once he did some more testing, for which he is awaiting our
Intel-Mac port.  Fortunately Eric McCorkle sent us just the patch we
need, so that should exist soon.

I talked with Suresh Jagannathan, who along with grad students Luke
Ziarek and Philip Schatz are working on CML and adding multicore
support for MLton.  I complained that they should use the MLton list
more to discuss their developments and include the community -- he
promised they would.

In general, multicore seemed to be an important theme of the week and
continues to rise on my own list of where it's important for MLton to
go next.  I hope to see progress on that front after the 64-bit port
is completed.

End of notes.