Type classes

[Fergus Henderson]

Hi,

David Jeffery and others may wish to have a look at the following paper.

> To: haskell at dcs.gla.ac.uk
> Subject: Type classes
> Date: Wed, 09 Apr 1997 13:13:58 -0700
> From: Simon L Peyton Jones <simonpj at cse.ogi.edu>
> 
> Folks,
> 
> There's often been quite a bit of discussion on the Haskell mailing list
> about extensions of type classes.  Erik Meijer, Mark Jones and I have
> written a draft paper that explores the type-class design space, discussing
> the various design decisions one must make, and their consequences. 
> (Location below.)
> 
> One thing the paper needs is more concrete examples.  This message is to
> encourage you to grab the paper, and 
> 
> 	a) Check which design choices would permit or prohibit the
> 	   programs you wish you could write in Haskell but can't.
> 	   (For example, many people have asked for multi-parameter
> 	   type classes... but as the paper discusses there are numerous
> 	   other aspects of the type-class system that affect which
> 	   programs are expressible.)
> 
> 	b) Tell us your conclusions, preferably in concrete form. For
> 	   example "The following program requires that we make
> 	   design choice 3b, and not 3a".  (The paper identifies
> 	   9 decisions, and several choices for each decision.)
> 
> Of course, any other feedback about the paper would be most gratefully
> received too.
> 
> The paper will appear in the (informal) proceedings of the Haskell workshop
> (7 June in Amsterdam).  We have to produce camera ready copy by 1 May.
> So feedback before end April would be most useful.
> 
> Simon
> ===============================================================
> 
> 	Type classes: an exploration of the design space
> 	Peyton Jones, Jones, Meijer
> 	http://www.cse.ogi.edu/~simonpj/multi.ps.gz
> 
> 
> When type classes were first introduced in Haskell they were regarded as a
> fairly experimental language feature, and therefore warranted a fairly
> conservative design.  Since that time, practical experience has convinced
> many programmers of the benefits and convenience of type classes.  However,
> on occasion, these same programmers have discovered examples where seemingly
> natural applications for type class overloading are prevented by the
> restrictions imposed by the Haskell design.
> 
> It is possible to extend the type class mechanisms of Haskell in various
> ways to overcome these limitations, but such proposals must be designed with
> great care.  For example, several different extensions have been implemented
> in Gofer.  Some of these, particularly the support for multi-parameter
> classes, have proved to be very useful, but interactions between other
> aspects of the design have resulted in a type system that is both unsound
> and undecidable.  Another illustration is the introduction of constructor
> classes in Haskell 1.3, which came without the proper generalization of the
> notion of a context.  As a consequence, certain quite reasonable programs
> are not typable.
> 
> In this paper we review the rationale behind the design of Haskell's class
> system, we identify some of the weaknesses in the current situation, and we
> explain the choices that we face in attempting to remove them.
> 
> 
> 


-- 
Fergus Henderson <fjh at cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3         |     -- the last words of T. S. Garp.