#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: #8541 -------------------------------------+------------------------------------ Comment (by goldfire): Yes, the depth-bound seems sensible and is probably the only real solution to this problem. We should be aware of a particularly nasty case, like this: {{{ Coercible (Maybe (Fix Maybe)) (Fix Maybe) }}} This should be solvable (and I posit that more sensible cases might come up in practice). The current algorithm simplifies the left-hand type (LHT) as far as it can, then simplifies the right-hand type (RHT) as far as it can. I would worry that the depth would hit its maximum when reducing the LHT and then refuse to simplify the RHT. Even if we tracked depths separately for the two sides, the right side would hit the maximum depth right before the two sides unify, leading to failure, no matter what the depth is! Note that if we just switch the order of the arguments to `Coercible`, this goal is easy to solve, after one reduction on the LHT. Having the solubility of a symmetric constraint depend on the order of arguments is undesirable. I have no good ideas of how to fix this, at the moment. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8503#comment:21 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler