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

[Matthew Fluet]

>  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.

The piece that is in SMLSC that is not in MLBs is that SMLSC allows you to 
compile against an interface without having the implementation immediately 
available.  With MLBs, we need to elaborate some body of code to determine 
the basis environment under which the new code is elaborated.  If there 
was some way to express a basis environment directly, then you would have 
something much like SMLSC with MLBs.

> 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.

Just from my brief reading of the UM specification, it sounds like there 
is a lot of array access going on, so I'm not surprised about the hit from 
bounds checks.  It would be nice to have a stronger bounds check removal 
pass.

> 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.

Those who have watched the recent SML/NJ working versions have seen the 
debut of a new lexical generator tool (based on derivatives of regular 
expressions).  They are also pretty close to completing a new parser 
generator tool (based on the ANTLR parsing technology).