Superclass defaults

[Ryan Newton]

>
> My only input is that we have at least 2-3 (depending on whether the
> latter two are to be considered separate) hierarchies in want of
> refactoring: Functor/Applicative/Monad, Num and friends, and Monoid.
> Ideally any solution would "solve the problem" for all of them, but
> even if it doesn't (and only solves, say, Monad's case), I think it
> should be a requirement that it at least allows for the others to be
> solved as well in an incremental fashion afterwards (whether by
> 'upgrading' the by-then existing feature, or adding a new, orthogonal
> one). The undesirable scenario would be where you would have to
> "change the world" all over again a second time to resolve the
> remaining problems.
>

Another place where this might help would be with the
RandomGen/SplittableGen issue:

   http://hackage.haskell.org/trac/ghc/ticket/4314

If "design goal 1" is met, then clients would not have to refactor their
Random instance to match the new class factoring.

-Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20110815/bc950df6/attachment-0001.htm>