Simon Peyton-Jones wrote:

| >> Have we considered Restricted Data Types? | >> | >> http://www.cs.chalmers.se/~rjmh/Papers/restricted-datatypes.ps | > | | Finally, I wrote my paper before fundeps came on the scene. Some of the contortions I went through | in my simulation of RDTs could be avoided with the help of fundeps.

A key point in the RDT paper, I think, was the ability to *abstract over a type class*. Now that is something one could consider adding to Haskell, as the SYB3 paper argues. (See my home page.)

Suppose that one could abstract over a type class. How would the RDT paper change? I'm not sure.

Simon

To do the same things as the RDT paper, one would need to abstract over type classes in both types and classes, and write functional dependencies between types and classes (to express the fact that a Set monad determines the Eq constraint on its arguments, for example). Disadvantages of doing it this way: * There's nowhere you can declare, once and for all, that the constraint associated with Set a is Eq a. If you make Set an instance of many classes (Collection, Monad, Functor...) you'll have to supply Eq as the corresponding class every time you do so. It's cleaner to associate Eq with Set once, and once only, at the type definition of Set. * RDTs *force* the inclusion of wft constraints--just allowing abstraction over classes would not do so. Now the question arises, should the Monad class, for example, be revised to parameterise over a class also? If not, then you still can't make Set an instance of Monad. If so, then you have the problems of passing extra dictionaries around anyway. John