Successor-ML

SuccessorML[1], 1ML[2], etc. are pretty close to this in spirit. I've been trying to keep up with the publications around the future of ML, but academic research moves kinda slowly. I'm hopeful we'll see a new definition of Standard ML this decade. I'd tend to agree SML is a great choice -- SML-1997 is still ahead of many languages that came well after it in both features and usability. [1] https://github.com/SMLFamily/Successor-ML [2] https://people.mpi-sws.org/~rossberg/1ml/

That's effectively not true[1]. [1]: https://github.com/SMLFamily/Successor-ML

> No, I mean that neither Elm nor Standard ML has nor needs typeclasses. No language needs typeclasses. Standard ML has less need for type classes because it has a much more expressive module system, but it still can be extremely tedious to pass around module definitions all the time, which is why they added equality types when the language was originally designed. This is considered an ugly hack though, even by its own creators [0]. Definitely agree that folks should aim for better than type classes, especially due to complications around global instance coherence. One nice solution is modular implicits/instance arguments [1][2]. Tricky thing is to do it without adding too much complexity to the language. I do wish that there would just be some acknowledgment that it's a hard, but real problem to solve for Elm's point in the design space

I work with a bunch of people who were very involved in SML, and I've asked this question many times. They usually say that SML (as a language) stagnated because of personal conflicts in the standardisation committee. A bit of a "worse is better" microcosmos, really, with a focus on on discussing theoretical perfection instead of how to get things into the hands of users. You can partially see this in play today in the Successor-ML[0] discussions, where there's not really any clear vision or leadership driving things forward, just a lot of (often very good) language suggestions. My own extrapolation is that a multitude of SML implementations meant that programmers couldn't take advantage of implementation-specific extensions, as that would prevent their code from running elsewhere. This hindered real-world experimentation (as opposed