Proposal: merge Data.Functor.Coproduct into transformers

[Edward Kmett]

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 <hesselink at gmail.com> wrote:

> 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
> >
>
> _______________________________________________
> 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/20121211/d72753ea/attachment.htm>