Add rules involving `coerce` to the libraries

With #2110 (closed) fixed, we can now add rules like

{-# RULES "map/coerce" [0] map coerce = coerce #-}

to the standard libraries. But probably this should happen together or after #8718 (closed).

Trac metadata

Trac field	Value
Version	7.9
Type	Task
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	libraries/base
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

mentioned in issue #2110 (closed)

mentioned in issue #8718 (closed)

changed weight to 5

added Ttask Trac import core libraries labels

mentioned in commit 6f338dd0

changed milestone to %7.8.1

Trac metadata

Trac field	Value
Version	7.9 → 7.8.1-rc2

added 1 deleted label

Trac metadata

Trac field	Value
Test case	→ tests/simplCore/should_run/T2110.hs

Please excuse the completely stupid commit message.

But, there should be many more similar RULES than just this, no? For example, any lawful Functor instance should have a RULE for its fmap, as I understand.

I don’t think there is a point in merging this into 7.8; the support for coerce in rules was added to master after the freeze ([b4715d67] up to [cde88e20]).

closed

Ah, I see. In that case that's fine - it's strictly an optimization, so I'm don't really care about missing this little thing.

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed

removed 1 deleted label

reopened

(Whoops, accidentally closed.)

Richard, Edward probably has something to say about the fmap rule, but in general do we want it right now when it can break things? I'm under the impression there's not a sensible and safe one we can write that won't break for non-lawful Functors. (I guess we can tell everyone to always write ones that obey the rules, but I'm not sure how much that might backfire).

There was some discussion of related approaches a few months ago around ICFP time (don't have a link on me). Anyway, worth a good discussion.

Trac metadata

Trac field	Value
Resolution	ResolvedFixed → Unresolved

I still believe that people should be free to write non-law-abiding instances (or maybe law-abiding up to some interface), and the compiler should not interfere with that.

We should simply suggest them to add a fmap coerce = coerce rule for their particular fmap if they care.

You can defintely have users write the rule for particular functors of course, but that means reasonably polymorphic code that is too complicated to INLINE will get penalized asymptotically, so in the long run I'd really like to find a better solution that might have a chance of firing on my code. ;)

Right. I forgot that #2110 (closed) isn't getting into 7.8. Then, neither should this.... which is good, because I agree that maybe some more thought is required.

I was not suggesting that there be a blanket fmap coerce --> coerce rule, just that we should add the specific rules for all the individual (lawful) Functors that we define. I agree completely that users should be free to write unlawful Functors if they wish to do so.

I don't believe there's a link to earlier discussions on fmap coerce issue because the discussions happened among actual humans, in an actual room, instead of among computers online. It's an amazing thought. In any case, I remember one conclusion being a suggestion to add a new method to Functor being fmapCoerce :: Coercible a b => f a -> f b. This would have a default implementation of fmapCoerce = fmap coerce (no surprise there) but could be reimplemented where there would be a performance improvement.

Returning to Edward's comment, I guess I don't understand the limits of the RULES mechanism to respond all that intelligently. In Core, anything that looks like fmap coerce in the source code would look something like $fmapIdForSomeInstance <type parameters> (\x -> x |> co). This should be easy enough to match at the Core level. If it's impossible to write a RULE that desugars to the pattern above, then I think it's a bug (er, feature request) in the RULES mechanism, not a call for a change to the Functor definition.

Though I'm not dead set against fmapCoerce in Functor, I believe that if we have to add such a thing, then there is a weakness in our design somewhere. During the conversations at ICFP, I was unaware of #2110 (closed) and Joachim's efforts to fix that bug. Now that we have that fixed, I believe fmapCoerce should be avoidable.