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