[GHC] #9792: map/coerce rule never seems to fire

[GHC]

#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]:

 > 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
 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