Jules Bean wrote:
Try again without missing out the list...
Peter Padawitz wrote:
> Jules Bean wrote:
>> Incidentally, I question why the "compFoo" are methods. Why not
just make them polymorphic functions? They don't look like you expect
instances to change them. The code continues to compile if I make them
functions and amend their signatures as required.
>
> I put compFoo into the class for the same reason why /= is part of
the class Eq: both functions are unique as soon as the others have
been instantiated.
I believe you misunderstand the reason.
/= is part of Eq in case a particular instance has a particularly
efficient way to implement /=, rather than using not and (==).
"Being unique as soon as the others are implemented" is not a reason
not to make it a method.
It might not have been the reason, but it is a nice effect that is often
taken advantage of.
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.
compBlock :: (Java block command intE boolE) => Block -> block
compBlock = block_ . map compCommand
still retains that property.
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
