I fully agree with Iavor. The correctness criterion is
the declaration
class C a b | a -> b
implies that the following implication must hold:
C a1 b1, C a2 b2, a1 ~ a1 ===> b1 ~ b2
That implication lets us derive the proof of type equality, which we
can use for improving other
> | 1. mutual dependencies:
> | class Add x y z | x y -> z, x z -> y, y z -> x
> | I think this example can be emulated with type functions; the
> | emulation didn't work with GHC 6.10, at least. It may work now.
> (The example you give is a bit odd because you specified that the
> types
> | Is there a policy that only a proposal's "owner" can modify the wiki
> | page? Or that you have to be a member of the Haskell' committee?
>
> I'm not sure. Malcolm Wallace is chair at the moment; I'm ccing him.
I have no idea: I neither set up the wiki, nor do I have any interesting adm
Okay, we seem to be having a debate where, to caricature only a
little, I'm arguing that Fundeps/UndecidableInstances are ugly but
useful, and other people are arguing that they are truly absolutely
horrible in their current GHC implementation. I think the debate
boils down to where you see the sc
First of all, I do agree with David. Overlapping instances are indeed
very useful in practice, cutting down significant amount of
boiler-plate. His examples, as well the example from polymorphic map
libraries (mentioned earlier) are real-world cases where overlapping
instances are invaluable and i
