|WikiProject Computer science|
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 184.108.40.206 (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)
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)
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)
Type classes & Interfaces
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. --220.127.116.11 (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 18.104.22.168 (talk) 21:36, 29 August 2015 (UTC)