#8543: `Coercible` ought to work for recursive newtypes --------------------------------------------+------------------------------ Reporter: nomeata | Owner: nomeata Type: task | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8503 --------------------------------------------+------------------------------ Changes (by simonpj): * cc: dimitris@…, sweirich@…, diatchki (added) * status: new => closed * resolution: => duplicate Old description:
At least on a best-effort basis.
The approach (developed by SPJ and me) is to
A) Add a feature to the constraint solver to prevent recursive dictionaries for specially marked instances (for now only used for `Coercible`). Rationale: Such dictionaries (which are fine for most classes like `Show`) would make `coerce` diverge. Implementation: Use the depth counter and do not use lower depths to solver constraints with a higher depth. This is of course a very conservative approximation, but should be sufficient.
B) Use the regular constraint depth bound to prevent looping at compile time. In order for that to be more useful, count constraint solving and type function resolving separately.
New description: The approach (developed by SPJ and me) is to A) Add a feature to the constraint solver to prevent recursive dictionaries for specially marked instances (for now only used for `Coercible`). Rationale: Such dictionaries (which are fine for most classes like `Show`) would make `coerce` diverge. Implementation: Use the depth counter and do not use lower depths to solver constraints with a higher depth. This is of course a very conservative approximation, but should be sufficient. B) Use the regular constraint depth bound to prevent looping at compile time. In order for that to be more useful, count constraint solving and type function resolving separately. -- Comment: I think it's better to keep this ticket with #8503, which has all the context. I've moved the comment there. Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8543#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler