Talk:Type class

From Wikipedia, the free encyclopedia

Contents 1 Comparison 2 Redirected 3 SML eqtypes 4 Broken links

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)