[GHC] #13264: GHC panic with (->) generalization branch while compiling lens
GHC
ghc-devs at haskell.org
Sat Feb 11 00:11:04 UTC 2017
#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
More information about the ghc-tickets
mailing list