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
implementation.
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
instantiated!
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.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe