Now maybe Elm should stay simple and not jump all the way to multi-parameter type classes with functional dependencies, but it is already forced to pay some of the complexity burden to decide which types admit equality testing, comparison and so on.
Now maybe Elm should stay simple and not jump all the way to multi-parameter type classes with functional dependencies, but it is already forced to pay some of the complexity burden to decide which types admit equality testing, comparison and so on.
Instead, there's this temporary hack[0]:
> Note: Equality (in the Elm sense) is not possible for certain types. For example, the functions (\n -> n + 1) and (\n -> 1 + n) are “the same” but detecting this in general is undecidable. In a future release, the compiler will detect when (==) is used with problematic types and provide a helpful error message. This will require quite serious infrastructure work that makes sense to batch with another big project, so the stopgap is to crash as quickly as possible. Problematic types include functions and JavaScript values like Json.Encode.Value which could contain functions if passed through a port.
As you say, Haskell's version of (==) has the type Eq a => a -> a -> Bool, and function types do not belong to Eq.
[0]: http://package.elm-lang.org/packages/elm-lang/core/5.1.1/Bas...
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.
Surely, if we agree that Eq, Ord, and Foldable are useful, they’re probably not the only useful type classes in existence.