G'day all. Quoting Janis Voigtlaender <[EMAIL PROTECTED]>:
Okay, it is quite natural to take this stand. But as you say, there is no such commitment in the language definition. And even if there were, I doubt it would be possible to enforce such invariants in a compiler. So there would be "illegal" programs that are nevertheless accepted by the compilers. Not what we want, do we, in Haskell land?
I guess this is, at its core, a philosophical question: Does the existence of default implementations imply that any specialised implementation must do the same thing (modulo strictness, efficiency etc) as the default one? I don't know the answer to that.
Agreed. I was about to answer that the situation is the same with the monad laws not being valid for some monad we all love, and still we do not consider the resulting programs illegal.
I do! The H98 report says that all Monad instances must obey the monad laws. If they don't, they're illegal. (As an aside: The H98 report still list the right-zero law as being a law for MonadPlus, even though most MonadPlus instances don't obey it. That's actually a defect in the report.)
But your point about the associativity law for Monoid is correct: these laws do not turn up as preconditions for a free theorem.
Right. And in that case, there's a clear reason why. The precondition for (Alg a) essentially says that the mapping function g :: C1 -> C2 must be a Alg-homomorphism. That implicitly assumes that C1 and C2 are both valid Alg-es, so if there are any "laws" of Alg, C1 and C2 both obey them by fiat.
So we are back to those invariants that are expressed as default instances. For Eq the invariant is quite obvious. But what about Ord? Certainly there is also an invariant that can be observed from its default instances, but I don't see how it could be read off mechanically.
You could, from a dependency analysis, automatically work out a minimal set of methods which are needed to satisfy the class. In the case of Ord, for example, it doesn't seem too hard to deduce that you could either use (==) and (<=), or (==) and compare. (You can't, unfortunately, mechanically deduce that (==) can be defined in terms of compare, despite what the last sentence of section 6.3.2 in the report says.) Now that I look at it, the report notes that: -- Note that (min x y, max x y) = (x,y) or (y,x) but never says that this requirement is mandatory.
A more general solution here would really be welcome.
In general, it'd be nice to be able to get the compiler to check that you've implemented at least a minimal set of operations in your class instance. Cheers, Andrew Bromage _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe