4 ms·

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, cohe

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 10y ago
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 10y ago
  What other languages do type classes like Haskell?
  - MustardTiger 10y ago
    All of them? Who else has broken almost like typeclasses other than scala?
    - codygman 10y ago
      All of the languages? Go doesn't have them. Neither does C.
      - MustardTiger 10y ago
        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 10y ago
        So basically what you are saying is "Haskell has Haskell's typeclasses!". That's a yuuuuge amount of languages that follow "Haskell"'s design! (Maybe you should start counting Haskell-to-X compilers separately to pad the number "1" a bit?)
        MustardTiger 10y ago
        Please read the posting guidelines and contribute constructively or not at all.
        premium-concern 10y ago
        I have already mentioned three languages that haven't followed Haskell's broken mess, while you have failed to produce even a single bit of information, while constantly crying foul at everything you don't like? That's just amazingly hypocritical, but I guess the tactic of "blame other people for your own behaviour to make it look like tu-quoque if they respond" hasn't gotten old for you yet?
        MustardTiger 10y ago
        I did not read your responses to other people, since you are obviously trolling. Your three examples are nonsense, two are haskell style, and one doesn't have type classes at all (ocaml).
        premium-concern 10y ago
        Ok, so if I understand you correctly: you claim that your failure to contribute anything of substance should be blamed on your inability to read and your lack of any knowledge of the topic. Well enough, sir.
  - premium-concern 10y ago
    Not these (at least): Idris – implicit arguments Agda – instance arguments OCaml – Modular implicits :-)
tome 10y ago
> 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 10y ago
  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 10y ago
    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.

MustardTiger 10y ago

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 10y ago
What other languages do type classes like Haskell?
- MustardTiger 10y ago
  All of them? Who else has broken almost like typeclasses other than scala?
  - codygman 10y ago
    All of the languages? Go doesn't have them. Neither does C.
    - MustardTiger 10y ago
      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 10y ago
        So basically what you are saying is "Haskell has Haskell's typeclasses!". That's a yuuuuge amount of languages that follow "Haskell"'s design! (Maybe you should start counting Haskell-to-X compilers separately to pad the number "1" a bit?)
        MustardTiger 10y ago
        Please read the posting guidelines and contribute constructively or not at all.
        premium-concern 10y ago
        I have already mentioned three languages that haven't followed Haskell's broken mess, while you have failed to produce even a single bit of information, while constantly crying foul at everything you don't like? That's just amazingly hypocritical, but I guess the tactic of "blame other people for your own behaviour to make it look like tu-quoque if they respond" hasn't gotten old for you yet?
        MustardTiger 10y ago
        I did not read your responses to other people, since you are obviously trolling. Your three examples are nonsense, two are haskell style, and one doesn't have type classes at all (ocaml).
        premium-concern 10y ago
        Ok, so if I understand you correctly: you claim that your failure to contribute anything of substance should be blamed on your inability to read and your lack of any knowledge of the topic. Well enough, sir.
- premium-concern 10y ago
  Not these (at least): Idris – implicit arguments Agda – instance arguments OCaml – Modular implicits :-)

tome 10y ago

> 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 10y ago
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 10y ago
  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.