Trex illegal? overlapping instances for derived classes -- is this intended?
Anthony Clayden
anthony.d.clayden at gmail.com
Tue Sep 20 00:59:18 UTC 2022
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/hugs-bugs/attachments/20220920/6aa79f73/attachment.html>
More information about the Hugs-Bugs
mailing list