[willtim]

It we would be easy to add simple built-in constraints for things like equality, without jumping all the way to full-blown type classes. This would be a very minimal change to the type checker and should not require a rewrite.

[runeks]

This example with the absence of an Eq class is not related to just equality, it’s a symptom of a lack of generics. You’ll end up with a lot of special, built-in classes (e.g. Ord), while just adding simple type classes to Elm would make all of this solvable in a library (e.g. Elm’s Prelude).

Surely, if we agree that Eq, Ord, and Foldable are useful, they’re probably not the only useful type classes in existence.

[willtim]

I think the Elm folks are playing a waiting game. There are alternatives to type-classes such as the proposed modular implicits for OCaml.

[endgame]

I'm not thrilled by languages the do "rules for thee, not for me". (Another example: old Java had a two-valued enum type (bool) but you weren't allowed to make your own.)

[willtim]

Agreed in general, but equality is so fundamental that I could forgive any built-in support. Even Haskell has "deriving Eq" built-in for example.

[tel]

That said the deriving mechanisms have been mostly exposed to the end used now in at least a few different ways.

Even more importantly, deriving doesn't change the semantics of the language. You could in principle do exactly the same things without deriving as you can with.