Superclass defaults

Ryan Newton rrnewton at
Mon Aug 15 22:59:40 CEST 2011

> 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:

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Glasgow-haskell-users mailing list