
I'm not wedded to its current behavior of wrapping an Either. It was kind
of nice that converting to and from Either was a no-op on GHC, but that
could change.
I agree that I wouldn't want to add functions named 'left' and 'right', so
moving to a data type rather than a newtype seems reasonable.
Perhaps
data Coproduct f g a = LeftF (f a) | RightF (g a)
would be a nice color for the bikeshed?
-Edward
On Tue, Dec 11, 2012 at 4:27 AM, Erik Hesselink
Are the 'left' and 'right' functions also going to be inlcuded in the move? Because if we're worried about clashes with base, those names are also defined in Control.Arrow.
In general I'd prefer the Sum name, but I'd +1 either name.
Erik
On Tue, Dec 11, 2012 at 5:54 AM, Mario Blazevic
wrote: At the instigation of Edward Kmett, I hereby propose to merge Data.Functor.Coproduct module from comonad-transformers into transformers.
The module defines the Coproduct data type, together with several class instances. All non-base instances would have to be left out, leaving the following instances to be merged in:
instance (Functor f, Functor g) => Functor (Coproduct f g) instance (Foldable f, Foldable g) => Foldable (Coproduct f g) instance (Traversable f, Traversable g) => Traversable (Coproduct f g)
Unfortunately, the Applicative and Monad instances cannot be defined on this type, though their duals can. In that sense, the existing comonad-transformers package is a more fitting home for the type. However, there are good reasons for the move:
- The dual type of Coproduct, namely Data.Functor.Product, is already defined by transformers. It would make sense to keep the duals together. - Data.Functor.Compose and Data.Functor.Constant which also defined by transformers are not monads either, so there is precedent for having non-monads there. - Most obviously, transformers is a haskell-platform package while comonad-transformers seems unlikely to become one any time soon (as much as I'd like that). - The existing Comonad instance can be moved from comonad-transformers to comonad; it would not be orphaned.
The patch against the darcs repository is attached.
An alternative naming for the module (and the type) would be Data.Functor.Sum. This name would be shorter and less frightening to newcomers, but it clashes with its namesake type from Data.Monoid. On the other hand, so does Data.Functor.Product. I'm ambivalent on the naming, but I'm throwing this out because I don't expect it to become a bikeshed issue. If you have any name preference, state it together with your vote; if the proposal succeeds we can use whichever name is preferred.
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries