mpl VS smlpkg

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 incurs a cost, but also exposes parallelism.

In the paper, we present our scheduler and prove a worst-case performance bound. We specifically show that the total overhead of promotion will be at most a small constant factor (e.g., 1% overhead), and also that the theoretical amount of parallelism is unaffected, asymptotically.

All of this is implemented in MaPLe (https://github.com/mpllang/mpl) and you can go play with it now!

Maple is a fork of MLton: https://github.com/MPLLang/mpl

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

They don't matter, since the package manager is entirely concerned with files. The Futhark package manager was actually ported to SML in the form of smlpkg. How those files are made available to the compiler is not the problem of the package manager. In SML's case, it's done with MLB files (which are part of the packages).

University Of Copenhagen who previously used SML for introductory programming courses (Now uses F#) have made a package manager for SML modules with MLB files: https://github.com/diku-dk/smlpkg

I wrote a package manager that sounds similar to what you are proposing. An important design criteria was that it was easy to understand and simple to implement, even at the cost of some clumsiness in use. I wrote about the design before and after I implemented it. It is based on a cut-down version of Go's package manager, and has itself served as the basis for a package manager for SML.