fmapCoerce / changes in 7.8

[Edward A Kmett]

A very real problem with making such a class is it basically forces a tension on any library to make two versions of literally everything.

Consider the case of lens, which makes incredibly aggressive use of such fmap-likes to put on and take off newtypes and does very little else.

All the combinators that do so would have to duplicate to work in such a world. Because now such an instance may not exist. This is mapM vs traverse for library authors, but it is an unforced error here.

There are three agents involved in consumption and production of such  an instance:

The author of the library that demands it, the author of the library that needs to supply it and the end user of both. In my experience, making a separate class like this only really works when these three roles are partitioned among two people. 

You need to support data types not supplied by the library, and not supplied by the end user.

The rest of the time it leads to a ratsnest of orphans and missing instances for something that should be supportable for every functor.

I've tried this. The result isn't maintainable for the library author or the user.

The reason we had Austin revert the patch was because this approach wasn't sufficient to solve the problem, so we backed off of it until Richard can get us better tools for composing Coercible witnesses, to let us upgrade this to something that can give you O(1) lifting over abstract transformer stacks.

When it is exiled to some other class, that sort of code just becomes something that isn't safe to use, and in many cases like while writing a transformer, isn't possible to use.

We introduce an unnecessary tension and duplication for authors and users.

-Edward

> On Sep 26, 2013, at 3:59 AM, David Luposchainsky <dluposchainsky at googlemail.com> wrote:
> 
> I'm also sceptical about this, regardless of whether it sounds like a
> good idea now. Adding a function to a typeclass is trivial, removing it
> later far from it (see fail, some, many). On the other hand, are there
> reasons not to create
> 
>> class Functor f => FunctorC f where
>>    fmapC :: Coercible a b => f a -> f b
> 
> instead?
> 
> 
> David/quchen
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs