Proposal: merge Data.Functor.Coproduct into transformers

[Edward Kmett]

+1 for it, sans bikeshedding, as Coproduct.

-Edward

On Mon, Dec 10, 2012 at 11:54 PM, 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20121210/b2b3db42/attachment.htm>