[kmiroslav]

> It has better type classes

Haskell and Scala win and lose on different criteria but for type classes, I find Haskell's syntax and semantics infinitely more elegant, more terse and more flexible than Scala's. Defining type classes in Scala is a cacophony of syntax boiler plate riddled with implicits and brackets. Haskell is much more elegant in that area.

[premium-concern]

Scala's typeclasses are first-class values and they actually work as advertised.

Haskell's type classes are a mess because Haskell-the-spec (anti-modular, coherent) and Haskell-the-language (incoherent, "modular") work completely different and nobody cares and there us no real fix because both options suck, as soon as your project consists of more than one module.

It's the reason why no language after Haskell does type classes the Haskell way, and all of them do it similar to Scala's approach.

Could Scala have more syntax sugar? Sure! But people are more focused on getting them right first, before adding additional syntax.

[MustardTiger]

What on earth are you talking about? Tons of other languages do type classes "the haskell way". Which is also known as "type classes". Scala doesn't have type classes, it has a close approximation.

[codygman]

What other languages do type classes like Haskell?

[MustardTiger]

All of them? Who else has broken almost like typeclasses other than scala?

[codygman]

All of the languages? Go doesn't have them. Neither does C.

[MustardTiger]

Obviously, all of the languages with type classes. Those languages do not have "type classes" like scala does, which is what I was replying to.

[premium-concern]

Not these (at least):

Idris – implicit arguments

Agda – instance arguments

OCaml – Modular implicits

:-)

[tome]

> Haskell-the-spec (anti-modular, coherent) and Haskell-the-language (incoherent, "modular") work completely different

I'm unaware of any such difference. Please explain.

[premium-concern]

The spec mandates that type class instances can only be defined together with the type class or with the corresponding data type.

While it's a very poor idea as no person except the author of the type class or the author of the data type can define a type class instance, it at least guarantees the global uniqueness and coherence of type class instances. ("There can only ever be a single typeclass instance for typeclass A and data type B.")

GHC (the only implementation that kind of matters today) takes a YOLO approach, allows as many typeclass instances as you want, doesn't bother enforcing the rules laid out in the spec. Additionally, as type class instances are not first-class values of the language a developer doesn't even have the option to make sure he is getting the instance he expects.

There exists a GHC warning for "orphan type class instances"–but as the warning triggers on everything, not only the relevant cases where multiple instances clash and break the program–it's as useful as saying "we made sure that C's goto-fail bug can never happen again by emitting a warning for every suspicions indentation – you only have to sift through 1732 warnings until you find the dangerous one!".

[dllthomas]

Your C comparison at the end is disingenuous. It is entirely possible to use the orphan instances warning to ensure coherence in an application that contains orphan instances without a single spurious warning. Simply make a habit of putting all orphan instances in a single module, and mark only that one module -fno-warn-orphans. The rest of your code can be organized appropriately. It is not ideal, but not painful.

It's true that you can't safely define orphan instances in a library, but that also should involve no "sifting through" warnings for valid uses. It is genuinely bad practice to put orphan instances in a library, even if we had global checking - it would produce cases where you simply cannot use otherwise compatible libraries in the same project.

[premium-concern]

Your idea of centralizing things into a module assumes you have control over all code ever written.

This might be true for the 90% of Haskell that is created and abandoned by PhDs writing their theses, but if you look at other language communities: People like to use a library from time to time.

[dllthomas]

You're being deliberately obnoxious in your phrasing. Cut it out.

Regarding your content:

You are making (or missing) a point I made above, and moving goal posts.

If you are writing a library that defines a new type and would like to provide an instance of some classes, there is no problem, those are not orphans.

If you are writing a library that defines a new class and would like to provide an instance for some types, there is no problem, those are not orphans.

If you are writing an application, the approach I suggested for the context of working on an application is entirely appropriate - you write orphan instances, and have a static check that they are coherent.

There is a bit more trouble if I am a library wanting to provide an instance of a class that I do not define, for a type that I do not define. Allowing orphan instances in this case, with or without a static check for coherence, assumes consumers of my library "have control over all code ever written" - it will either be dangerous (without a check) or forbidden (with a check) that they use my library with (potentially seemingly unrelated) libraries. The correct workaround is usually to provide a newtype, for which you can define non-orphan instances. This is not bad, but it certainly is a bit of a tradeoff.

But again, you moved the goal posts. I made no general claim about the suitability of Haskell's expectation of coherence. I objected to your false claim that maintaining coherence involves picking over spurious warnings about orphan instances. It does not.