Maybe it is possible to abstract over the constraints somehow, and write a constraint with value ⊥ in the general case, circumventing any special casing for Coercible?
(But even if it is possible it includes so much malice that whoever does
#9792: map/coerce rule never seems to fire -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:8 nomeata]: that waives any right to complain about `map coerce = coerce` :-)) There's a lot I don't understand (including the two comments above), but here's what I think I do understand: 1. Destroying the evidence: If GHC can get its hands on the concrete evidence, it will erase it, because it has the proof it needs. If it can't, it conservatively assumes that the evidence could be `_|_`, because getting this wrong would break the type system. This situation is somewhat unfortunate—if we can ensure the evidence is never bottom, we can be certain never to incur a runtime coercion cost. But without a proof the compiler gurus are unlikely to make that leap, and the people who've spoken up so far are not aware that anyone has proved it. One question in my mind is how this relates to #9701, and also whether GHC ensures that the evidence is as small as possible (coerce itself presumably can be a 0-size token, if it isn't already). 2. Polymorphic `map coerce`, or more generally letting `RULES` get hold of a boxed up `coerce`: The situation here is far less dire. Replacing `map coerce` with `coerce` when coerce is bottom will turn a list of bottoms into bottom. Obviously, that wouldn't be wonderful, but it also wouldn't break the type system. I think that's the sort of thing that would be okay to implement optimistically and wait and see if anything breaks. What's involved in implementing it I wouldn't know. My understanding was that `coerce` is mostly about making things as efficient as possible ''in the face of lots of polymophism'', so just accepting inefficiency because things are too polymorphic doesn't sound right here. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9792#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler