
#8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): Posted this to ghc-devs. Realizing it makes more sense here: I've run up against a limitation of `Coercible` I'd like to know more about. Currently, the stage2 compiler on my branch fails to build because of the problem. In Module.lhs, there is this line: {{{ newtype PackageId = PId FastString deriving( Eq, Typeable ) }}} The deriving mechanism sensibly prefers to use the GND mechanism when it can, and it can (seemingly) for `Eq` here. But, I get this error: {{{ compiler/basicTypes/Module.lhs:297:46: No instance for (ghc-prim:GHC.Types.Coercible FastString PackageId) because ‛PackageId’ is a recursive type constuctor }}} This is curious, because `PackageId` is manifestly ''not'' recursive. A little poking around tells me that any datatype mentioned in a .hs-boot file is considered recursive. There is sense to this, but the error message sure is confusing. In any case, this opens up a broader issue: we want GND to work with recursive newtypes. For example: {{{ class C a where meth :: a instance C (Either a String) where meth = Right "" newtype RecNT = MkRecNT (Either RecNT String) deriving C }}} The above code works just fine in 7.6.3. But, if `Coercible` isn't allowed over recursive newtypes, then this wouldn't work if GND is implemented in terms of `coerce`. So, my question is: why have this restriction? And, if there is a good reason for it, it should probably be documented somewhere. I couldn't find mention of it in the user's guide or in the haddock docs. If we do keep this restriction, what to do about GND? Seems like this may kill the idea of implementing GND in terms of `coerce`, but that makes me sad. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8503#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler