mpl

While interesting on a surface level, I find this paper curious. What it describes here is essentially a roundabout way to try and express open type associations ("extending the data set" as it calls it) when the class hierarchy is already occupied as a primitive cognate to sum-types. This is more or less just a grammar to express type classes stapled over a class hierarchy grammar. I think the almost pun-like structure of that is funny, but in all actuality this feels pretty needless. The strangest aspect of it is that they cite Haskell. Given the date of the paper, I would understand unfamiliarity with Haskell given the implementations[1] that were available at the time weren't very "useful" if you had any kind of latency requirements on your software. That being said it's strange that somebody in 1998 would write a paper like this, kn

Nowadays 210 is actually parallel! You can run 210-style code using MaPLe (https://github.com/MPLLang/mpl) and get competitive performance with respect to C/C++. If you liked 210, you might also like https://futhark-lang.org/ which is an ML-family language that compiles to GPU with good performance.

I'm one of the authors of this work -- I can explain a little. "Provably efficient" means that the language provides worst-case performance guarantees. For example in the "Automatic Parallelism Management" paper (https://dl.acm.org/doi/10.1145/3632880), we develop a compiler and run-time system that can execute extremely fine-grained parallel code without losing performance. (Concretely, imagine tiny tasks of around only 10-100 instructions each.) The key idea is to make sure that any task which is *too tiny* is executed sequentially instead of in parallel. To make this happen, we use a scheduler that runs in the background during execution. It is the scheduler's job to decide on-the-fly which tasks should be sequentialized and which tasks should be "promoted" into actual threads that can run in parallel. Intuitively, each promotion incur

For promising modern and parallel GC techniques please check MPL or MaPLe with its novel Automatic Management of Parallelism. It won distinguished paper award in POPL 2024 and ACM SIGPLAN dissertation award 2023 by proposing these two main things [1],[2]: a) Provably efficient parallel garbage collection based on disentanglement b) Provably efficient automatic granularity control [1] MaPLe (MPL): https://github.com/MPLLang/mpl [2] Automatic Parallelism Management: https://dl.acm.org/doi/10.1145/3632880

I wish Mojo or any other other languages for intensive data processing and HPC would consider techniques proposed by MPL with its novel Automatic Management of Parallelism. It won distinguished paper award in POPL 2024 and ACM SIGPLAN dissertation award 2023 by proposing these two main things [1],[2]: a) Provably efficient parallel garbage collection based on disentanglement b) Provably efficient automatic granularity control [1] MaPLe (MPL): https://github.com/MPLLang/mpl [2] Automatic Parallelism Management: https://dl.acm.org/doi/10.1145/3632880

This is both a comprehensive guide, and an excellent reference! I use it often when writing SML for side projects. For those interested in parallel, functional programming, I recommend taking a look at Futhark, which leverages data parallelism to make very fast parallel programs. It is based on SML, and has similar syntax, but can automatically build programs that (among other targets) run on the GPU using CUDA or OpenCL. It is also worth checking out MPL, which extends the (already awesome) whole-program optimizing compiler MLton to add support for nested, fork-join parallelism. https://github.com/diku-dk/futhark https://github.com/MPLLang/mpl

Some of us are still using SML for research and teaching, e.g. https://github.com/mpllang/mpl

Good to get an update on multicore. On the other side of the pond, parallel MLton [0] is making solid progress. And Poly/ML [1] has had pthreads for a while. [0] https://github.com/MPLLang/mpl [1] https://www.polyml.org/documentation/Reference/Threads.html