#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