What was wrong with SML?

#1

Post by rdpintqogeogsaa » Sat, Apr 30, 2022, 6:10 PM UTC

What was wrong with SML?
blog.plover.com

Re: What was wrong with SML?

#2

Post by pjmlp » Sat, Apr 30, 2022, 7:27 PM UTC

What was wrong is not having a killer application or an industry giant pushing it.

Grammar and language semantic are details regarding language adoption.

Re: What was wrong with SML?

#3

Post by throwamon » Sat, Apr 30, 2022, 7:33 PM UTC

A bit off-topic, but could someone ELI5 what a lattice is in this context?

Re: What was wrong with SML?

#4

Post by chombier » Sat, Apr 30, 2022, 7:34 PM UTC

> Scala has a very different solution to this problem, called covariant and contravariant traits.

I thought Scala had an even stricter value restriction than ML, where only function/methods may get a polymorphic type?

Re: What was wrong with SML?

#5

Post by chombier » Sat, Apr 30, 2022, 7:42 PM UTC

throwamon wrote: post #3

A bit off-topic, but could someone ELI5 what a lattice is in this context?

I think this refers to a system of types in which for any two types there is also an union type and an intersection type in the lattice.

Re: What was wrong with SML?

#6

Post by porcoda » Sat, Apr 30, 2022, 7:42 PM UTC

I still actively use SML - mlton or smlnj usually, polyml too. I’m aware of the issues raised in this post but haven’t ever found them to be a source of much headache. To be honest, the biggest headache is moving between compilers and their different build processes. Other than that, the fact that the language isn’t really changing is a big attraction for me.

CakeML is also a very cool project in SML land.

Re: What was wrong with SML?

#7

Post by eatonphil » Sat, Apr 30, 2022, 7:49 PM UTC

I mentioned to Mark when I saw this, and he noted it in the addendum at the end, that calling Standard ML dead is a bit too much. I've written recently [0] about how active it surprisingly is.

I also disagree that its failure to "succeed" has anything to do with syntax or semantics and solely that it doesn't have a Jane Street or any company publicly behind it.

[0] https://notes.eatonphil.com/standard-ml-in-2020.html

Re: What was wrong with SML?

#8

Post by eatonphil » Sat, Apr 30, 2022, 7:50 PM UTC

pjmlp wrote: post #2

What was wrong is not having a killer application or an industry giant pushing it. Grammar and language semantic are details regarding language adoption.

Yup, adoption has nothing to do with being a sensible language. More often it seems to be completely inversely related.

Re: What was wrong with SML?

#9

Post by porcoda » Sat, Apr 30, 2022, 7:59 PM UTC

eatonphil wrote: post #7

I mentioned to Mark when I saw this, and he noted it in the addendum at the end, that calling Standard ML dead is a bit too much. I've written recently [0] about how active it surprisingly is. I also disagree that its failure to "succeed" has anything to do with syntax or semantics and solely that it doesn't have a Jane Street or any company publicly behind it. [0] https://notes.eatonphil.com/standard-ml-in-2020.html

I don’t think it succeeded or failed. Languages don’t need to be wildly popular in industry to be valuable. I personally like that industry ignores SML. Even for Ocaml I don’t use the Jane street core: I just use the stock language since it’s small and stable. I like that Jane street helps improve the core compiler though.

Re: What was wrong with SML?

#10

Post by Athas » Sat, Apr 30, 2022, 8:05 PM UTC

> Haskell's primary solution to this is to burn it all to the ground. Mutation doesn't cause any type problems because there isn't any.

This is true, but I think it is also misleading. Haskell has the same problem if you use unsafePerformIO to create a polymorphic IORef at top level. You can then use this IORef to subvert the type system. I think this is something many Haskell programmers are not fully aware of: unsafePerformIO doesn't just break referential transparency; it can also fundamentally break memory safety. Now, you may say that unsafePerformIO is obviously unsafe (it's in the name!) and should never be used. But if you look at many foundational Haskell libraries, you will find that they use unsafePerformIO or similar functions internally, usually for performance reasons. What are the rules that govern safe usage of unsafePerformIO? As far as I can determine, these rules are basically just GHC implementation details, and people often get them wrong. And if you break these rules, you don't just get a function that doesn't do what you expected - you may have subverted memory safety entirely.

I think this is an interesting conundrum. Haskell makes much stronger promises than SML, but if you break the rules, all bets are completely off.