#4815: Instance constraints should be used when deriving on associated data
types
---------------------------------+------------------------------------------
Reporter: batterseapower | Owner:
Type: feature request | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 6.12.3
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
Comment(by batterseapower):
But if you ever have a value of type "Associated (Maybe a)" then you
pretty much know that there must be a "Foo a" instance by looking at the
"Foo (Maybe a)" instance. So you aren't losing much generality in practice
by requiring that stronger constraint, rather than the weaker Eq
constraint.
(I haven't tried it, but perhaps it's possible to add new instances to an
associated data family outside of the instance itself? In which case the
logic above is not valid, but since this is a rather uncommon use case I
don't think this should argue against my proposed behaviour change. And
anyway if you know the weaker constraint is enough and you *really want*
to use it because you're going to extend the data family outside an
instance itself for some reason, then you can use standalone deriving with
the weaker constraint)
It seems to me that just using the instances' constraints is a reasonable
thing to do by default, as it stands the very best change of allowing
deriving to work. I personally prefer a more reliable deriving mechanism
to one that works less often but when it does, generates more general type
class instances.
(BTW, personally I find it slightly surprising that you can even mention
the type "Associated a" without mentioning "Foo a" in your type signature,
though I can kind of see the reasoning)
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4815#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
