MLton and MPL relationship question?

[bikallem]

Is mpl (this repo) going to be merged back to MLton(https://github.com/MLton/mlton)? Or is this a new fork of SML with parallel programming support? What is the roadmap? Is this mainly just for research purposes rather than general usage?

Thanks.

[shwestrick]

Great question. I'd be curious to hear @MatthewFluet's thoughts on the relationship between MPL and MLton. I feel that, although there is significant overlap in the underlying design, the high-level goals are different.

Regardless, the development of MPL and MLton are intertwined. I expect we will continue to see ideas from MLton migrated into MPL, and vice versa. We've already identified a few things in MPL that could possibly improve MLton's performance. Perhaps eventually the two systems could converge on a common runtime system (with different memory management strategies).

Is this mainly just for research purposes rather than general usage?

Our goal is for MPL to be more generally usable, not just in research. MPL is already being used for educational purposes, both at CMU and elsewhere. Hopefully the community will continue to grow!

[bikallem]

Perhaps eventually the two systems could converge on a common runtime system (with different memory management strategies).

Is the difference between mpl and mlton mostly runtime? What I mean is mlton has some pretty impressive feature set as advertised in http://mlton.org/Features. Does the said so feature set still hold for mpl? Will I be correct in my understanding to say that mpl is mlton with multicore/parallel programming support? Specifically, does the following still hold for mpl?

Performance

Executables have [excellent runtime performance](http://mlton.org/Performance).

Generates small executables.

MLton takes advantage of whole-program compilation to perform very aggressive dead-code elimination, which often leads to smaller executables than with other SML compilers.

Untagged and unboxed native integers, reals, and words.

In MLton, integers and words are 8 bits, 16 bits, 32 bits, and 64 bits and arithmetic does not have any overhead due to tagging or boxing. Also, reals (32-bit and 64-bit) are stored unboxed, avoiding any overhead due to boxing.

Unboxed native arrays.

In MLton, an array (or vector) of integers, reals, or words uses the natural C-like representation. This is fast and supports easy exchange of data with C. Monomorphic arrays (and vectors) use the same C-like representations as their polymorphic counterparts.

Multiple [garbage collection](http://mlton.org/GarbageCollection) strategies.

Fast arbitrary precision arithmetic (IntInf) based on [GMP](http://mlton.org/GMP).

For IntInf intensive programs, MLton can be an order of magnitude or more faster than Poly/ML or SML/NJ.

[MatthewFluet]

MPL is most definitely a fork of MLton, in the sense that the vast majority of the sources are shared. We have periodically merged MLton upstream changes into MPL and, when it makes sense, I've ported some changes from MPL back to MLton.

The compiler proper is very similar between the two systems. MPL has a couple of extra primitive operations that need to be handled by some of the optimization passes, but, on the whole, the diff of the compiler proper is fairly small. But, the runtime system is very different now (though, some basics of object representation remain the same).

All of the features that @bikallem quoted are present in MPL, with the exception of "Multiple Garbage Collection strategies." Actually, both MLton and MPL have multiple gc strategies, but pretty much none in common any more. MPL has MLton's same FFI, though one would need to be a little more careful, since the FFI functions could be called from multiple threads.

I'd love to further minimize the diff between the two systems. It has be a long-standing (but pretty much only infrastructure gruntwork) task to try to define a "Runtime Interface" for MLton that would make it easier to deploy different runtimes that could be selected among at compile time.

[shwestrick]

Closing this now. Thanks for the questions @bikallem! Let us know if you're curious about anything else.