Jules Bean wrote:
Try again without missing out the list...
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
Peter Padawitz wrote: 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.