[Haskell-cafe] Re: type class question
peter.padawitz at udo.edu
Mon Dec 10 10:12:01 EST 2007
Jules Bean wrote:
> Peter Padawitz wrote:
>> Jules Bean wrote:
>>> Peter Padawitz wrote:
>>>> What is so bad about making compFoo part of the class? It reduces
>>>> the code (constraints can be avoided) and reflects the close
>>>> connection between a signature Sig (implemented by the class) and
>>>> the evaluation (compFoo) of Sig-terms in Sig-algebras.
>>> making it part of the class allows instances to override the
>>> Which in this case is a strange thing to do.
>> Sure, but this can only happen because Haskell does not check whether
>> the instances satisfy the equations in the class. The type class
>> concept would be "cleaner" if all methods (partially or totally)
>> defined by equations within the class were not allowed to be
> I don't see why!
> In the class
> class Foo a where
> f :: a -> Int
> g :: b -> Integer
> g = fromIntegral . f
> The equations within the class are defaults, not equations.
I must admit that I didn't know this... Nevertheless, won't you agree
that the default and the actual instance should be semantically equivalent?
> The equation for 'g' is a default, not a rule.
> If you want equations, you do it outside the class. I have written
> that class wrongly, I should actually write g = fromIntegral . f as a
> function outside the class, thus guaranteeing the implementation and
> stopping people breaking that invariant.
> The purpose of methods with defaults is to allow the possibility that
> there is an obvious natural way to implement one function in terms of
> others, but there might be more efficient ways.
> For example, the Foldable class should (but doesn't) have a member
> length. This could be defaulted to length . toList, but have a more
> efficient implementation in Sequence, which stores its own length anyway.
> Or maybe we are at cross-purposes.
No no, default functions make sense.
More information about the Haskell-Cafe