[chriseidhof]

Every added feature also adds complexity (and to be fair, in some cases, removes complexity). I love type classes, but I discovered in playing with Elm and specifically, TEA (The Elm Architecture) that the simplicity is also really nice even if you're comfortable doing type-level programming. There's something about Elm's simplicity that really works.

[endgame]

Agreed, but Elm is hurting for some way to deal with this stuff. Currently, the API reference lies by claiming things like (==) : a -> a -> Bool, because it lacks a generic mechanism to let the programmer think the necessary thoughts. (The story for comparison functions like (>) is similar.)

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.

[ryanplant-au]

Can you elaborate on what you mean when you say that (==) : a -> a -> Bool is a lie? I don't have enough experience with more powerful type systems to know what the more accurate claim would be. Do you mean that it should really be Eq a => a -> a -> Bool, because not all types can be checked for equality?

[endgame]

That's exactly what I mean: A type like a -> a -> Bool says that it will work for _any_ a, but we can easily find counter examples. We could pass in functions (say) and write something like (\x -> x * 2) == (\x -> x + 1). The type signature for (==) as written says it _should_ work, but it doesn't because there's no general way to compute function equality.

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...

[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.