I had it pretty well worked out for single parameter type classes, but I couldn't see any nice extension to multiple parameters.

On Dec 11, 2007 5:30 PM, Simon Peyton-Jones < simonpj@microsoft.com> wrote:
| If it really would work ok we should get it fully specified and
| implemented so we can fix the most obvious class hierarchy problems in a
| nice backwards compatible way. Things are only supposed to be candidates
| for Haskell' if they're already implemented.

Getting it fully specified is the first thing.

Personally I am not keen about

a) coupling it to explicit import/export (independently-desirable though such a change might be)

b) having instance declarations silently spring into existence


Concerning (b) here's a suggestion.  As now, require that every instance requires an instance declaration.  So, in the main example of http://haskell.org/haskellwiki/Class_system_extension_proposal, for a new data type T you'd write
       instance Monad T where
         return = ...
         (>>=)  = ...

       instance Functor T
       instance Applicative T

The instance declaration for (Functor T) works just as usual (no explicit method, so use the default method) except for one thing: how the default method is found.  The change is this:
   Given "instance C T where ...", for any method 'm' not
   defined by "...":
       for every class D of which C is a superclass
       where there is an instance for (D T)
       see if the instance gives a binding for 'm'
   If this search finds exactly one binding, use it,
       otherwise behave as now

This formulation reduces the problem to a more manageable one: a search for the default method.

I'm not sure what is supposed to happen if the instance is for something more complicated (T a, say, or multi-parameter type class) but I bet you could work it out.

All these instances would need to be in the same module:
  - you can't define Functor T without Monad T, because you
       want to pick up the monad-specific default method
  - you can't define Monad T without Functor T, because
       the latter is a superclass of the former

It still sounds a bit complicated.

Simon
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users