>    import Hugs.Trex
>    
>    type UserId = Int
>    type EventId = Int
>    
>    data Message
>      = SendChat (Rec ( message :: String,  user :: UserId ))
>      | Signup   (Rec ( eventId :: EventId, user :: UserId ))
>      deriving (Eq)

>

There's an `instance Eq Message` -- fine.

From Hugs.Trex I get (and these are fine)

>    instance EqRecRow a => Eq (Rec a)                -- pass through to a specialised class

>    instance EqRecRow EmptyRow

These are generated by the `deriving`; note they're not specialised to the field's type, nor for rows with combinations of labels:

>      instance (Eq a, b\eventId, EqRecRow b) => EqRecRow (eventId :: a | b)

Not specialising and not combining labels makes sense: then no clash if I also had:

>    data Probe a b c
>      = MkProbe (Rec (user :: a, message :: b, eventId :: c))
>      deriving (Eq)             

But those generated instances for `EqRecRow` overlap in no substitution ordering -- as Hugs tells me if I try to declare them explicitly. How does a wanted for `(MkProbe x) == (MkProbe y)` resolve to the wanted instances? There's no preference ordering -- or is there?

Precisely because it's Trex where records are considered isomorphic up to permutation of labels; and because each instance has an `EqRecRow b` constraint for the rest of the row; it doesn't matter how Hugs resolves the wanted to the instances: it'll get to the same answer. But I don't see how this fits with Hugs usual approach for overlaps.

AntC