[Haskell-beginners] Re: Classes in Polymorphic Constructors

[Brandon S Allbery KF8NH]

-----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 at kf8nh.com
system administrator  [openafs,heimdal,too many hats]  allbery at 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-----