[GHC] #10448: Implement rest of "Add bifunctor related classes to base"-Proposal

[GHC]

#10448: Implement rest of "Add bifunctor related classes to base"-Proposal
-------------------------------------+-------------------------------------
        Reporter:  hvr               |                Owner:
            Type:  task              |               Status:  new
        Priority:  normal            |            Milestone:  8.0.1
       Component:  libraries/base    |              Version:
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #9682             |  Differential Rev(s):  Phab:D336
-------------------------------------+-------------------------------------

Comment (by RyanGlScott):

 Ed pointed out to me that one possible stumbling block in migrating
 `Bitraversable` to `base` is
 [http://hackage.haskell.org/package/bifunctors-5/docs/Data-
 Bitraversable.html its current definition]:

 {{{#!hs
 class (Bifunctor t, Bifoldable t) => Bitraversable t where
     bitraverse :: Applicative f => (a -> f c) -> (b -> f d) -> t a b -> f
 (t c d)
     bisequenceA :: Applicative f => t (f a) (f b) -> f (t a b)
     bimapM :: Monad m => (a -> m c) -> (b -> m d) -> t a b -> m (t c d)
     bisequence :: Monad m => t (m a) (m b) -> m (t a b)
 }}}

 Like `Traversable`, `Bitraversable` currently has two duplicate method
 signatures with stronger constraints (`Monad` instead of `Applicative`).
 We should probably aim to make `bimapM` and `bisequence` top-level
 definitions instead of class methods during the migration, but there has
 been a lingering question of whether this would affect runtime
 performance.

 AFAICT, the consensus is that any remaining obstacles to redefining `mapM
 = traverse`
 [https://mail.haskell.org/pipermail/libraries/2015-May/025723.html have
 been overcome] since #8189 was fixed, so is there any reason that we
 couldn't also redefine `bimapM = bitraverse` and `bisequence =
 bisequenceA`?

 Other than that, I don't see any reason why we couldn't migrate
 `Data.Bifoldable` and `Data.Bitraversable` as they're implemented right
 now. One thing that was a concern for `Foldable` (#9621) was turning
 functions like `toList` into class methods for efficiency purposes, but I
 can't think of a `Bifoldable` instance that would benefit significantly
 from this, so we can probably leave that aside.

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