Proposal: merge Data.Functor.Coproduct into transformers

[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 <mblazevic at stilo.com> 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>