#4528: stand-alone deriving sometimes fails for GADTs
------------------------------------------+---------------------------------
Reporter: nestra | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler (Type checker) | Version: 7.0.1
Keywords: deriving mechanism, GADTs | Testcase:
Blockedby: | Difficulty:
Os: Linux | Blocking:
Architecture: x86_64 (amd64) | Failure: Compile-time
performance bug
------------------------------------------+---------------------------------
Comment(by simonpj):
Thanks for pointing this out.
It's not reasonable to derive an `Enum` instance for a GADT. Consider
{{{
data T a where
T1 :: T Int
T2 :: T Bool
T3 :: T a
}}}
What would `[T1 ..`] be? Clearly not `[T1,T2,T3]` because that would be
ill-typed. Perhaps `[T1,T3] :: T Int`? It is very far from clear. I
have added a check to treat GADTs as non-enumerations.
The same holds for `Bounded`. After, all `minBound` for `T` should have
type
{{{
minBoundT :: forall a. T a
}}}
but the `minBound` is `T1`, which doesn't have that type.
For `Read` things are less clear. In general the "standalone deriving"
mechanism generates the boilerplate code and typechecks it; if it doesn't
typecheck you get a complaint (see #3012). So the error messages for
`Read` seem right. Situation is different for `Enum` because it uses the
primop `tagToEnum#` which must be treated with care.
I'll commit a fix shortly.
Simon
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4528#comment:1>
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
