[Haskell-cafe] class default method proposal
s.clover at gmail.com
Tue Dec 11 12:59:06 EST 2007
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
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
> | 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.
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
More information about the Haskell-Cafe