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.
