Talk:Type class

Comparison

Are type classes analogous to interfaces in object oriented programming? --Pezezin 11:56, 20 September 2006 (UTC)

I've seen interfaces used as an analogy, but I think I also saw it said somewhere that interfaces are not as theoretically powerful as type classes. -- Gwern (contribs) 14:55, 20 September 2006 (UTC)

Type classes plus existential types can model interfaces in object oriented programming, but interfaces can neither model type classes nor existential types. —Preceding unsigned comment added by 217.50.128.15 (talk) 21:16, 23 April 2008 (UTC)

Even if correct, it is disingenuous to talk about type classes without comparing them to similar constructs in other languages. Type classes did not just appear out of a vacuum. Not only are they very much like interfaces, but they are also akin to mixins in Ruby (e.g. Enumerable). Moreover, type classes, like interfaces and mixins, are essentially an implementation of a more general concept, the Abstract_type. But more to the point, the above quote to the contrary doesn't even make any sense, since interfaces are existential types. Transfire (talk) 13:28, 2 July 2014 (UTC)

Redirected

I've redirected "Bounded class" and "Bounded classes", which apparently are features of the upcoming Java 6, here since they seem to be versions of type classes. If this is wrong, the redirects should point somewhere else. --Gwern (contribs) 23:57, 2 November 2006 (UTC)

SML eqtypes

I have removed the following:

In contrast with the "eqtypes" of Standard ML, overloading the equality operator through the use of type classes in Haskell does not require extensive modification of the compiler frontend or the underlying type system.

This doesn't sound fair to me. Does "extensive modification" refer to adding support for equality types to a proto-SML compiler that does not support them yet? If so, then there's no contrast with Haskell: if Haskell didn't have type classes, then no overloading would be possible, and adding them would be an extensive modification! In fact, both languages have what they have and any compiler that needs to be changed to support the full language is not being "extensively modified", it's being "finished" after a very unfortunate start.

On the other hand, it is true that "instances" of the equality class in SML are all automatically derived, giving the programmer no control -- unless, I suppose, he or she extensively modified the compiler :) Many SML people think this is a deficiency. I've attempted a more neutral description of the situation. Cjoev 20:44, 5 February 2007 (UTC)

Your edits were good, but with the paragraph on Standard ML that large, it doesn't belong in the intro to the article anymore. So I moved it to its own section. Also, I got rid of the "researchers point out that..." bit because you have a good citation there, so you don't need those weasel words :-) SparsityProblem 22:40, 5 February 2007 (UTC)

My original purpose in mentioning eqtypes was to place the conception of type classes in some historical context. Language designers of the day had a limited number of methods for including overloading in a languge, and they were all flawed methods or at very least not up to the standards of the Haskell committee. This is illustrated in the beginning of "How to make ad-hoc polymorphism less ad hoc" and possibly in another paper by Simon Peyton Jones (which I'll look for).

Any mention of SML eqtypes should be brief; the topic does not warrant its own section. I think that the sentence that I originially wrote should be placed in the intro again. One or two more (short) sentences on eqtypes should follow it. After that, a brief mention of arithmetic overloading in SML and maybe Miranda should follow. I don't think that mentioning Miranda by name is necessary; it's more important that the article mention the approach of giving programmers a single number type to achieve "overloading". --seliopou 05:13, 7 February 2007 (UTC)

"Extensive modifcation" is referring to two comments: one made in "How to make ad-hoc polymorphism less ad hoc" and the other in "Standard ML of New Jersey". In the former the authors describe the way in which ML handles eqtypes, and they way that "eqtypeness" has to be propogated through types. The latter mentions that something around 7% of the code in the compiler frontend is dedicated to the implementation of eqtypes, a number that the authors themselves find astonishing.

The type systems of both Standard ML and Haskell are based on the Hindley-Milner type inference algorithm. Eqtypes require that this inference algorithm be modified in order to work (the propogation of the "eqtypeness"), while Haskell type classes in principle require absolutely no modification of the type system (as described in "How to make ad-hoc polymorphism less ad hoc").--seliopou 05:02, 7 February 2007 (UTC)

Broken links

Links to Haskell's wiki seems to be dead... —Preceding unsigned comment added by 82.233.237.207 (talk) 15:20, 24 November 2007 (UTC)

Type classes & Interfaces

Hello,

Could Type Classes be compared to Interfaces ?

May be some words about this comparison would be useful. Many people know about interfaces, so this could help to tell about in which way is comparable or not comparable. --80.185.187.249 (talk) 03:38, 27 May 2011 (UTC) [Hibou57]

First appearance of type classes

I slapped a "Citation needed" template on the claim that type classes first appeared in the Haskell programming language. The claim seems dubious--CLOS's classes and generic methods appear to capture the idea of type classes without carrying the label. Simões (^talk/_contribs) 01:49, 23 May 2012 (UTC)

member function example should be renamed

There's an example function (member :: (Eq a) => a -> [a] -> Bool).

The word "member" has a special meaning in the type systems of most languages. This conflicts with the subject of this article. It would be better to rename it "find" or "isIn". — Preceding unsigned comment added by 81.191.75.7 (talk) 21:36, 29 August 2015 (UTC)

That example confused me too! I've changed it to elem, since that's the name of the Haskell function.Mount Flatten (talk) 20:47, 15 September 2015 (UTC)

I'd like to see more on how type classes are used.

I think most people are interested in knowing how type classes are typically used. Maybe what the most common type classes are. Then, if people are still interested, the rest of this article seems to do a good job of describing what a type class *is*. Well, assuming that you know Haskell (or at least ML) and are comfortable with Monads... Which excludes 95% of computer programmers.

I think the same issue is true with "what's a monad" questions. The answer gets into complex category theory, but when people ask the question, they usually mean, "how is a monad used and what makes it useful?" --GlenPeterson (talk) 11:28, 29 March 2016 (UTC)

Agreed. Using monads as the usecase of the example is almost comically unhelpful. Is that a joke? Or out of spite? Or compete lack of self-awareness? Who knows.. 178.192.214.235 (talk) 19:39, 23 April 2022 (UTC)

See the usage of type class here. --Ancheta Wis   (talk | contribs) 02:37, 24 April 2022 (UTC)

A more general application using Listable Int String is shown here --Ancheta Wis   (talk | contribs) 19:05, 24 April 2022 (UTC)