Instances of multiple classes at once
Dylan Thurston
dpt@math.harvard.edu
Thu, 8 Feb 2001 14:55:14 -0500
(Superficially irrelevant digression:)
Simon Peyton-Jones came here today and talked about his combinator
library for financial applications, as in his paper "Composing
Contracts". One of the points he made was that a well-designed
combinator library for financial traders should have combinators that
work on a high level; then, when they want to start writing their own
contracts, they can learn about a somewhat smaller set of building
blocks inside that; then eventually they might learn about the
fundamental building blocks. (Examples of different levels from the
paper: "european"; "zcb"; "give"; "anytime".)
One theory is that a well-designed class library has the same
property. But standard Haskell doesn't allow this; that is why I like
the proposal to allow a single instances to simultaneously declare
instances of superclasses. One problem is how to present the
information on the type hierarchy to users. (This is a problem in
Haskell anyway; I find myself referring to the source of the Prelude
while writing programs, which seems like a Bad Thing when extrapolated
to larger modules.)
On Thu, Feb 08, 2001 at 09:41:56PM +1100, Fergus Henderson wrote:
> One point that needs to be resolved is the interaction with default methods.
>
> Consider
>
> class foo a where
> f :: ...
> f = ...
> f2 :: ...
> f2 = ...
>
> class (foo a) => bar a where
> b :: ...
>
> instance bar T where
> -- no definitions for f or f2
> b = 42
>
> Should this define an instance for `foo T'?
> (I think not.)
Whyever not? Because there is no textual mention of class Foo in the
instance for Bar? Think about the case of a superclass with no methods;
wouldn't you want to allow automatic instances in this case?
One might even go further and allow a class to declare default methods
for a superclass:
class Foo a where
f :: ...
class (Foo a) => Bar a where
b :: ...
b = ...
f = ...
Best,
Dylan Thurston