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.