6 ms·

I kinda wish the Haskell designers hadn't gone with the term "typeclass", as it's incredibly misleading. Typeclasses have a lot more cognitive similarity to Go

I kinda wish the Haskell designers hadn't gone with the term "typeclass", as it's incredibly misleading. Typeclasses have a lot more cognitive similarity to Go-style interfaces or Smalltalk protocols than they do to OOP-style classes, and that fact can be enormously confusing to newcomers (which, at times, seems to be the Haskell raison d'etre).

grabcocque 9y ago
Quite. Typeclasses are Haskell's way of doing ad hoc polymorphism. C++ has ad hoc polymorphism too, but it's via templates not classes.
- Veedrac 9y ago
  Typeclasses also do virtual dispatch, though. That comparison isn't much closer.
  - gpderetta 9y ago
    Not an Haskell expert (or even a beginner really, just generally interested in language design), but as far as I understand in 99% of the cases virtual dispatch in Haskell is purely an implementation detail: i.e. type classes can be implemented via monomorphization exactly like C++ templates (and in fact the compiler will do exactly that when optimising or when explicitly directed to do so); it isn't done by default mostly to preserve separate compilation and code explosion. There are cases where that can't be done at all (polymorphic recursion, when the recursion can't be proven to terminate at compile time, I'm sure there are other) and runtime dispatching is required, but that's more of an exception. In C++ that's implemented with explicit, semi manually implemented, type erasure wrappers. edit: as I said, I'm not an Haskell programmer; maybe in idiomatic Haskell the cases where runtime dispatch is required are much more common.
    - Veedrac 9y ago
      Imagine you have a problem for which you need virtual dispatch. In C++, you typically reach for inheritance. In Haskell, you typically reach for typeclasses. Comparatively, imagine you have a problem for which you need ad-hoc, but statically resolvable, overloads. In C++, you typically reach for templates. In Haskell, you instead typically reach again for typeclasses. This is what I mean when I say neither comparison is really closer than the other. Haskell couldn't replace typeclasses with templates, just as it couldn't replace them with objects.
dualogy 9y ago
Well this stuff happened in '88: http://homepages.inf.ed.ac.uk/wadler/papers/class-letter/class-letter.txt http://homepages.inf.ed.ac.uk/wadler/papers/class-letter/cla... --- they possibly didn't expect OOP and "classes" (Stroustrup '79) to become quite so very ubiquitous as they did in the 90s.
- mpweiher 9y ago
  Well, Smalltalk had been around for 16 years, Simula for over 20. The whole world of GUI programming was based on OO.
  - marcosdumay 9y ago
    The whole world of GUI programming consisted of a bunch of top of line labs and some research centers studying GUIs.
    - mpweiher 9y ago
      Huh? The Xerox Star was introduced in 1981 https://en.wikipedia.org/wiki/Xerox_Star https://en.wikipedia.org/wiki/Xerox_Star Apple's Lisa was introduced in 1983. https://en.wikipedia.org/wiki/Apple_Lisa https://en.wikipedia.org/wiki/Apple_Lisa With it, Lisa Toolkit and Clascal (Pascal with Classes) http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/apple/lisa/toolkit_university/Clascal_Reference_Manual_Mar83.pdf http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/app... The Mac in 1984 https://en.wikipedia.org/wiki/Macintosh_128K https://en.wikipedia.org/wiki/Macintosh_128K MacApp in 1985 https://en.wikipedia.org/wiki/MacApp https://en.wikipedia.org/wiki/MacApp The Tektronix 4404 running Smalltalk, also 1984 http://www.wirfs-brock.com/allen/files/tek/4404-Flyer.pdf http://www.wirfs-brock.com/allen/files/tek/4404-Flyer.pdf The Amiga and Atari ST in 1985. Windows was at 2.0 in 1987. Heck, the NeXT cube had been introduced by fall of '88. https://en.wikipedia.org/wiki/NeXT_Computer https://en.wikipedia.org/wiki/NeXT_Computer
- zzalpha 9y ago
  You... don't really think Stroustrup invented the term "class", do you? :)
evincarofautumn 9y ago
I think the logic behind the name is e.g. “‘Eq t’ is the class of types ‘t’ that support equality”, with “class” having the sense of “subset”.
- Jare 9y ago
  That's exactly how I think of it: Typeclass = a class of types, which makes my C++ brain think of templates not inheritance.
- zzalpha 9y ago
  Oh, I don't dispute the name is logical. I'm saying in the broader context of programming languages, it's confusing. And that that confusion could have been easily foreseen and avoided... after all, Smalltalk had been using the term "class" for almost 20 years before Haskell appeared and introduced their terminology.
  - mbrock 9y ago
    Haskell uses the words "type", "class", and "kind", and maybe some others too, which are all just simple English words that denote some form of abstract grouping ("form" and "group" I suppose are two other candidates). At least they're called "typeclasses" and not just "classes". But we're always going to have some overloading of these powerful short ancient words. I did recently see a suggestion to rename the "typeclass" keyword to "algebra" which would be pretty cool!
js8 9y ago
You should realize that the term "class" has also meaning in mathematics, which is a different meaning than in programming. So from mathematics perspective, the name is apt. I am not sure what other name you would suggest, anyway.
- cies 9y ago
  I think `interface` is probably the software engineering terminology that comes closest. Leading to: interface Eq a where (==), (/=) :: a -> a -> Bool x /= y = not (x == y) implement (Eq a) => Eq (Tree a) where Leaf a == Leaf b = a == b (Branch l1 r1) == (Branch l2 r2) = (l1==l2) && (r1==r2) _ == _ = False Not bad. But not a total game changer either. Probably makes more immediate sense for most new comers though.
  - js8 9y ago
    It is close but typeclasses are not interfaces either. They could have used a fashionable and somewhat overloaded term like "interface" or "protocol" or "trait" or "flavor", or they could have used an exact, albeit somewhat bland, name coming from mathematics. They did the latter. In fact, they have faced a similar choice for many aspects of the language, and in most cases, mathematical purity got precedence over practicality. Had they chosen differently, the result wouldn't be Haskell.
    - tome 9y ago
      > It is close but typeclasses are not interfaces either. Why not? They seem to be exactly interfaces to me. > They could have used a fashionable and somewhat overloaded term like "interface" or "protocol" or "trait" or "flavor", or they could have used an exact, albeit somewhat bland, name coming from mathematics. They did the latter. The terminology "class" in Haskell certainly has nothing to do with its mathematical meaning of "collection of sets defined by a predicate".
      - js8 9y ago

grabcocque 9y ago

Quite. Typeclasses are Haskell's way of doing ad hoc polymorphism. C++ has ad hoc polymorphism too, but it's via templates not classes.

Veedrac 9y ago
Typeclasses also do virtual dispatch, though. That comparison isn't much closer.
- gpderetta 9y ago
  Not an Haskell expert (or even a beginner really, just generally interested in language design), but as far as I understand in 99% of the cases virtual dispatch in Haskell is purely an implementation detail: i.e. type classes can be implemented via monomorphization exactly like C++ templates (and in fact the compiler will do exactly that when optimising or when explicitly directed to do so); it isn't done by default mostly to preserve separate compilation and code explosion. There are cases where that can't be done at all (polymorphic recursion, when the recursion can't be proven to terminate at compile time, I'm sure there are other) and runtime dispatching is required, but that's more of an exception. In C++ that's implemented with explicit, semi manually implemented, type erasure wrappers. edit: as I said, I'm not an Haskell programmer; maybe in idiomatic Haskell the cases where runtime dispatch is required are much more common.
  - Veedrac 9y ago
    Imagine you have a problem for which you need virtual dispatch. In C++, you typically reach for inheritance. In Haskell, you typically reach for typeclasses. Comparatively, imagine you have a problem for which you need ad-hoc, but statically resolvable, overloads. In C++, you typically reach for templates. In Haskell, you instead typically reach again for typeclasses. This is what I mean when I say neither comparison is really closer than the other. Haskell couldn't replace typeclasses with templates, just as it couldn't replace them with objects.

dualogy 9y ago

Well this stuff happened in '88: http://homepages.inf.ed.ac.uk/wadler/papers/class-letter/class-letter.txt http://homepages.inf.ed.ac.uk/wadler/papers/class-letter/cla... --- they possibly didn't expect OOP and "classes" (Stroustrup '79) to become quite so very ubiquitous as they did in the 90s.

mpweiher 9y ago
Well, Smalltalk had been around for 16 years, Simula for over 20. The whole world of GUI programming was based on OO.
- marcosdumay 9y ago
  The whole world of GUI programming consisted of a bunch of top of line labs and some research centers studying GUIs.
  - mpweiher 9y ago
    Huh? The Xerox Star was introduced in 1981 https://en.wikipedia.org/wiki/Xerox_Star https://en.wikipedia.org/wiki/Xerox_Star Apple's Lisa was introduced in 1983. https://en.wikipedia.org/wiki/Apple_Lisa https://en.wikipedia.org/wiki/Apple_Lisa With it, Lisa Toolkit and Clascal (Pascal with Classes) http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/apple/lisa/toolkit_university/Clascal_Reference_Manual_Mar83.pdf http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/app... The Mac in 1984 https://en.wikipedia.org/wiki/Macintosh_128K https://en.wikipedia.org/wiki/Macintosh_128K MacApp in 1985 https://en.wikipedia.org/wiki/MacApp https://en.wikipedia.org/wiki/MacApp The Tektronix 4404 running Smalltalk, also 1984 http://www.wirfs-brock.com/allen/files/tek/4404-Flyer.pdf http://www.wirfs-brock.com/allen/files/tek/4404-Flyer.pdf The Amiga and Atari ST in 1985. Windows was at 2.0 in 1987. Heck, the NeXT cube had been introduced by fall of '88. https://en.wikipedia.org/wiki/NeXT_Computer https://en.wikipedia.org/wiki/NeXT_Computer
zzalpha 9y ago
You... don't really think Stroustrup invented the term "class", do you? :)

evincarofautumn 9y ago

I think the logic behind the name is e.g. “‘Eq t’ is the class of types ‘t’ that support equality”, with “class” having the sense of “subset”.

Jare 9y ago
That's exactly how I think of it: Typeclass = a class of types, which makes my C++ brain think of templates not inheritance.
zzalpha 9y ago
Oh, I don't dispute the name is logical. I'm saying in the broader context of programming languages, it's confusing. And that that confusion could have been easily foreseen and avoided... after all, Smalltalk had been using the term "class" for almost 20 years before Haskell appeared and introduced their terminology.
- mbrock 9y ago
  Haskell uses the words "type", "class", and "kind", and maybe some others too, which are all just simple English words that denote some form of abstract grouping ("form" and "group" I suppose are two other candidates). At least they're called "typeclasses" and not just "classes". But we're always going to have some overloading of these powerful short ancient words. I did recently see a suggestion to rename the "typeclass" keyword to "algebra" which would be pretty cool!

js8 9y ago

You should realize that the term "class" has also meaning in mathematics, which is a different meaning than in programming. So from mathematics perspective, the name is apt. I am not sure what other name you would suggest, anyway.

cies 9y ago
I think `interface` is probably the software engineering terminology that comes closest. Leading to: interface Eq a where (==), (/=) :: a -> a -> Bool x /= y = not (x == y) implement (Eq a) => Eq (Tree a) where Leaf a == Leaf b = a == b (Branch l1 r1) == (Branch l2 r2) = (l1==l2) && (r1==r2) _ == _ = False Not bad. But not a total game changer either. Probably makes more immediate sense for most new comers though.
- js8 9y ago
  It is close but typeclasses are not interfaces either. They could have used a fashionable and somewhat overloaded term like "interface" or "protocol" or "trait" or "flavor", or they could have used an exact, albeit somewhat bland, name coming from mathematics. They did the latter. In fact, they have faced a similar choice for many aspects of the language, and in most cases, mathematical purity got precedence over practicality. Had they chosen differently, the result wouldn't be Haskell.
  - tome 9y ago
    > It is close but typeclasses are not interfaces either. Why not? They seem to be exactly interfaces to me. > They could have used a fashionable and somewhat overloaded term like "interface" or "protocol" or "trait" or "flavor", or they could have used an exact, albeit somewhat bland, name coming from mathematics. They did the latter. The terminology "class" in Haskell certainly has nothing to do with its mathematical meaning of "collection of sets defined by a predicate".
    - js8 9y ago