4 ms·

I love standard ml (I'm currently writing a compiler for it), but it's far from perfect. There are weird special cases in the language definition like the ad-ho

I love standard ml (I'm currently writing a compiler for it), but it's far from perfect. There are weird special cases in the language definition like the ad-hoc overloading between int and real, or the annoying value restriction. Records also feel half-baked, with no support for updating fields or for partially-specified records where the full set of fields is not known

mkehrt 11mo ago
I've written a fair amount of SML (though years ago) and I can't remember the value restriction ever being an issue. I certainly agree that SML isn't really a production language, though.
retrac 11mo ago
> with no support for updating fields While it's not yet standard nearly all Standard ML implementations support what has become known as "Successor ML" [0]. A large subset of Successor ML is common to SML/NJ, MLton, Poly/ML, MLKit and other implementations. That includes record update syntax, binary literals, and more expressive patterns among other deficiencies in Standard ML. For me the two big remaining issues are: 1) There's only limited Unicode support in both the core language and the standard library. This is a big issue for many real-world programs including these days the compilers for which SML is otherwise a wonderful language. 2) The module system is a "shadow language" [0] which mirrors parts of SML but which has less expressiveness where modules cannot be treated as first-class values in the program. Also if you define infix operators in a module their fixity isn't exported along with the function type. (Little annoyance that gets me every time I am inclined to write Haskell-style code with lots of operators. Though maybe that's just another hint from the universe that I shouldn't write code like that.) Of course, the fix to that would be a fundamentally different language; not a revised SML. [0] http://mlton.org/SuccessorML http://mlton.org/SuccessorML [1] https://gbracha.blogspot.com/2014/09/a-domain-of-shadows.html https://gbracha.blogspot.com/2014/09/a-domain-of-shadows.htm...
- jimbokun 11mo ago
  As I was saying, Successor ML is like OCaml, but perfect!

mkehrt 11mo ago

I've written a fair amount of SML (though years ago) and I can't remember the value restriction ever being an issue. I certainly agree that SML isn't really a production language, though.

retrac 11mo ago

> with no support for updating fields While it's not yet standard nearly all Standard ML implementations support what has become known as "Successor ML" [0]. A large subset of Successor ML is common to SML/NJ, MLton, Poly/ML, MLKit and other implementations. That includes record update syntax, binary literals, and more expressive patterns among other deficiencies in Standard ML. For me the two big remaining issues are: 1) There's only limited Unicode support in both the core language and the standard library. This is a big issue for many real-world programs including these days the compilers for which SML is otherwise a wonderful language. 2) The module system is a "shadow language" [0] which mirrors parts of SML but which has less expressiveness where modules cannot be treated as first-class values in the program. Also if you define infix operators in a module their fixity isn't exported along with the function type. (Little annoyance that gets me every time I am inclined to write Haskell-style code with lots of operators. Though maybe that's just another hint from the universe that I shouldn't write code like that.) Of course, the fix to that would be a fundamentally different language; not a revised SML. [0] http://mlton.org/SuccessorML http://mlton.org/SuccessorML [1] https://gbracha.blogspot.com/2014/09/a-domain-of-shadows.html https://gbracha.blogspot.com/2014/09/a-domain-of-shadows.htm...

jimbokun 11mo ago
As I was saying, Successor ML is like OCaml, but perfect!