| You can hear a bunch more about the full history of development of SML and interaction with OCaml here:
https://www.youtube.com/watch?v=NVEgyJCTee4 I would definitely agree with the opinion above that the SML language designers fall in the camp of deliberating extensively and fully formalizing all new language features before considering them for inclusion. Today, there are two challenges right now in the Successor ML space: - There's some broad agreement on a few things that should obviously be improved, but today many of the implementation owners don't have a huge amount of time, so getting them to also agree to the new features is complicated. Life is way easier when you only have one implementation. - There's a bunch of fantastic ideas (largely driven by Bob Harper) to integrate stuff like parallelism, cost model, etc. that will be fantastic for a next version of the language and specification. It's just a lot of work, and not really publishable, so it's mainly tenured faculty and "alumni" (like myself and probably the people you work with) driving it forward in our free time. That said, I still love working on SML and its implementations (I mainly contribute to SML/NJ and Manticore) and it's a wonderful escape from the grim reality of quarterly goals and "get it out the door" release deadlines :-) |
That's another thing I noticed - people are not really prototyping the new ideas. I know that Bob Harper and John Reppy are also working on other projects, so they probably can't invest much implementation time on SML anymore. I wonder how OCaml and Haskell managed to keep implementers active.
The Successor-ML feature I'm just curious about is modular implicits (or some of the other alternatives mentioned by Harper). I much prefer the SML module system to Haskell's type classes, except that it is notationally more cumbersome in use. Sprinkling a little bit of implicit behaviour (when choice of functor is unambiguous) would help a lot.