[Haskell-cafe] Re: type class question

[Peter Padawitz]

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.
>