#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

#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): -------------------------------------+------------------------------------- Changes (by hvr): * differential: Phab:D336 => -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10448#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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): -------------------------------------+------------------------------------- Comment (by ekmett): It is in the list of simplifications to consider for `Traversable`. If we can show it doesn't help measurably, it'd be a win for simplicity, and the `(bi)sequenceA` name that nobody likes can then eventually die in favor of `(bi)sequence`, whereas the other way there is no actual viable upgrade path that supports its removal. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10448#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#10448: Implement rest of "Add bifunctor related classes to base"-Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: patch Priority: normal | Milestone: 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:D2284 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"270d545d557352d5f264247987ee8388f0812187/ghc" 270d545/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="270d545d557352d5f264247987ee8388f0812187" Add Bifoldable and Bitraversable to base This adds `Data.Bifoldable` and `Data.Bitraversable` from the `bifunctors` package to `base`, completing the migration started in D336. This is fairly straightforward, although there were a suprising amount of reinternal organization in `base` that was needed for this to happen: * `Data.Foldable`, `Data.Traversable`, `Data.Bifoldable`, and `Data.Bitraversable` share some nonexported datatypes (e.g., `StateL`, `StateR`, `Min`, `Max`, etc.) to implement some instances. To avoid code duplication, I migrated this internal code to a new hidden module, `Data.Functor.Utils` (better naming suggestions welcome). * `Data.Traversable` and `Data.Bitraversable` also make use of an identity newtype, so I modified them to use `Data.Functor.Identity.Identity`. This has a ripple effect on several other modules, since I had to move instances around in order to avoid dependency cycles. Fixes #10448. Reviewers: ekmett, hvr, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2284 GHC Trac Issues: #9682, #10448 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10448#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler