Hugs-Bugs

Download

hugs-bugs@haskell.org

September 2022

1 participants
1 discussions

Trex illegal? overlapping instances for derived classes -- is this intended?
by Anthony Clayden 19 Sep '22

19 Sep '22

For derived instances I'm getting decls that aren't allowed if I try to put them explicitly. They're rejected as overlapping, and in no substitution ordering. > 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) > instance (Eq a, b\user, EqRecRow b) => EqRecRow (user :: a | b) > instance (Eq a, b\message, EqRecRow b) => EqRecRow (message :: 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

1 0