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
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
