-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/23/10 15:17 , John Smith wrote:
On 23/08/2010 20:28, Brandon S Allbery KF8NH wrote:
Typeclasses are not classes, and Haskell values are not objects. In OO languages, objects carry around dictionaries with full details of what they can do. Haskell values, on the other hand, don't actually carry around anything; what they can do is specified by the type. If the type is (Show a => [a]), that means the *only* thing you can do with an (a) is to call (show) on it.
(1) Since this is almost certainly not what you intend,
Wouldn't this be a useful feature? For example, [Show] could contain a list
It can be useful at times, which is why you can write it out the long way. But consider something like ([forall n. Num n => n]); the dictionary contains the basic math operations (see the definition of Num; you also get Eq and Show, but nothing else. Not even Ord, since complex numbers don't have a well defined ordering) and they are specialized for the exact type of the object, but you don't know what that type is so you can't really apply it to anything else. (Not even to another member of the list, since it doesn't have the type of that object, it has the type (forall n. Num n => n).) On the other hand, carrying around type and/or method information for every value is fairly expensive, and lazy languages are already slow because of the extra work (basically, "lazy" means every expression is actually a closure which produces the value of that expression when invoked). This is what "unboxing" is about, which you'll see mentioned in almost every discussion of optimization or performance in Haskell). Including a method dictionary means *another* level of indirection for every expression and every evaluation step, and then if you make the dictionary lazy as well then it's still another level of indirection per evaluation.
of values for serialising to strings, and ditto for any other typeclass. When you say "Since this is almost certainly not what you intend", is there something else which could be intended by such code?
Most people, on seeing that, would expect it to mean "I get to use all the operations legal on the type of the value I gave it, as long as that type is a member of Show". But it actually means "I can only use operations legal on values whose type is a member of Show".
I don't want OO, just for typeclasses to be usable as types in polymorphism, seeing as both are equally relevant as a definition of constraints. (There's probably a better way to word that.)
You may have phrased that wrongly indeed; I would recognize that as subtyping, which is a form of dependent types. Which is a rather more complex ball of type spaghetti. - -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxyzUYACgkQIn7hlCsL25VZVACgvX0aLQwioqkOSByVdfA9jAo5 MPIAoLR55POz5SjHki7Pcui7nmn1fS2u =8aCZ -----END PGP SIGNATURE-----