#13264: GHC panic with (->) generalization branch while compiling lens -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Maybe, but not necessarily. After all, the change we're proposing replaces a panic with a `Nothing`. In theory, no code (except the case we've identified in `can_eq_nc'`) should evaluate to the panic, so changing behavior there should have no effect beyond `can_eq_nc'`. However, practice does not always equate to theory, and this choice might change a helpful panic into very obscure behavior. So if the function ''is'' widely used, then I learn more toward the new-ADT approach: define something like {{{#!hs data SplitResult a b = Split a b | NotSplittable | NoRuntimeRep }}} where `NotSplittable` means that the type is a `FunTy` that would ordinarily be splittable, but retrieving the `RuntimeRep` failed. This failure should happen only when a) something is ill-kinded, or b) something needs a good zonk. This new ADT could be used in both `splitTyConApp` and `splitAppTy`. Or here's another approach: you're calling `tcRepSplitTyConApp_maybe`. Note the `tc`. How would we fare if this function were put into the `TcM` monad? Then, if the `RuntimeRep` were unavailable, we could zonk on the fly and succeed. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13264#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler