[comex]

> Elm handles those things the way Standard ML does, not the way Haskell does.

That's the thing, though: it doesn't. Sure, Elm is expressive enough to allow use of dictionary passing as a substitute for typeclasses, and as you noted, this approach has some resemblance to how ML modules work – albeit with less sugar. However, Elm's standard library does not seem to think this is the best approach, since it instead uses the aforementioned special-cased typeclasses.

[rtfeldman]

> use of dictionary passing as a substitute for typeclasses

No, I mean that neither Elm nor Standard ML has nor needs typeclasses. No language needs typeclasses.

Both Elm and Standard ML have additional type constraints for numbers and comparable types that aren't implemented in terms of a user-definable type constraint like Haskell's typeclasses.

Another example of their being different is that Haskell offers custom user-defined operators, whereas Elm intentionally does not allow user-defined operators. There are a fixed list of them, and that's it. A great many languages have that policy too, and I would not call them wrong to do it that way.

Again, there are sound design reasons to make either choice! There are costs and benefits to making things user-definable. If you prefer the way Haskell did it, great! That's why we have different programming languages. :)

[bjz_]

> 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, rather than just pretending it isn't there. It's ok just to say that you're not spending design capital on it at the moment due to more pressing issues!

[0]: https://github.com/SMLFamily/Successor-ML/issues/18

[1]: https://arxiv.org/abs/1512.01895

[2]: https://www.researchgate.net/profile/Dominique_Devriese/publ...

[Athas]

> Both Elm and Standard ML have additional type constraints for numbers and comparable types that aren't implemented in terms of a user-definable type constraint like Haskell's typeclasses.

That's not really true. Standard ML has overloaded operators for int/real, but you cannot write a polymorphic function over any kind of number without using the module system. This is a key distinction. Standard ML does have a notion of 'equivalence type variables', which is frequently seen as a wart (since you often get an equality definition you might not be interested in). Standard ML has nothing for 'comparable' types (except, again, through the module system).

Offhand, I can't really think of any other language that uses builtin type classes in the style of Elm.

[Skinney]

I guess Go is the only language which comes close, which has map and array/slice which cannot be implemented in the language itself. Though it's the lack of generics, not ad-hoc polymorphism which is Go's lack.

Then again, it wouldn't surprise me if of all the languages you've thought about, Elm is the only one which hasn't reached 1.0 yet.

I think Elm will get some mechanism of ad-hoc polymorphism before it reaches 1.0, but I don't think it will be type classes. Though, I have been wrong before.