[GHC] #11135: Migrate more of Data.Functor.* from transformers to base.

[GHC]

#11135: Migrate more of Data.Functor.* from transformers to base.
-------------------------------------+-------------------------------------
        Reporter:  hvr               |                Owner:
            Type:  task              |               Status:  upstream
        Priority:  highest           |            Milestone:  8.0.1
       Component:  libraries/base    |              Version:  7.10.2
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D1543
       Wiki Page:                    |  Phab:D1544
-------------------------------------+-------------------------------------

Comment (by ross):

 Replying to [comment:11 ekmett]:
 > Ryan: I'm really very negative on the idea of reverting to the old
 approach.
 >
 > We rather deliberately changed them in HEAD months ago to make it so
 that they can be used in more situations without requiring the `Functor`
 constraint a few months back, the old approach had rendered these classes
 useless for a lot of real world situations around GADTs and the like, in a
 way that simultaneously made implementations inefficient and less often
 applicable.
 >
 > The old transformers approach winds up requiring
 >
 > {{{#!hs
 > instance (Functor f, Eq1 f, Eq1 g) => Eq1 (Compose f g)
 > }}}
 >
 > while the current approach lets you use
 >
 > {{{#!hs
 > instance (Eq1 f, Eq1 g) => Eq1 (Compose f g)
 > }}}
 >
 > and the code works in one pass regardless of whether or not f and g are
 known.
 >
 > The price of admission is a manual implementation. The current
 compromise Ross has implemented gets a design that is readily implemented
 and implementable for a wide arrange of things.
 >
 > Now, we could modify the way we pass in the "manual dictionary" version
 of 'Show/Read' to allow the `showList`/`readList` trick to work. It'd
 admittedly make the classes harder to implement and use. I could get
 behind an alternative API that passed in more stuff to `readsPrecWith` and
 `showsPrecWith`, or one that added a second combinator so that most people
 didn't have to deal with the noise.
 >
 > I'd be okay with either proceeding with the status quo, or even more
 comfortable proceeding with a fix that modifies the methods in the `Show1`
 and `Read1` classes to pass more information, but it'd take a lot of
 convincing to bring me around to the old version in transformers,
 especially when we very consciously changed to get away from it!
 Yes, I'd come to the same conclusion, and have already made the necessary
 changes for `Show1`, and am now working through `Read1`.  Note that the
 version before the changes also gave the wrong output on `show (Compose
 (Just "abc"))`.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11135#comment:12>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler