Another suggestion, maybe completely off the wall, would be to do something with stand-alone deriving syntax? So instead of "instance Functor T" one might write "deriving Functor for T" ? This might make it more clear that default methods were being brought into play. With this syntax, it would seem appropriate to me that any case of overlap would produce an error (modulo, perhaps, some funny new ghc flag such as -fallow-overlapping-derivations). --s. instance Monad T On Dec 11, 2007, at 12:30 PM, Simon Peyton-Jones 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