Proposal: merge Data.Functor.Coproduct into transformers
Edward Kmett
ekmett at gmail.com
Sat Dec 15 10:36:12 CET 2012
I'd be willing to go with Sum(InL, InR) to move us toward consensus, then Sum has a majority and InL|InR are the most common constructor choices. They are fairly traditional as well.
Sent from my iPad
On Dec 14, 2012, at 2:37 PM, Mario Blažević <mblazevic at stilo.com> wrote:
> So far we have a consensus on the proposal (yay!), but no firm agreement on the naming. Of the two alternatives I've suggested, Sum appears to have edged ahead of Coproduct. Let me know if I misrepresented anybody's position:
>
> Edward Coproduct (LeftF | RightF)
> Erik Sum
> Wren Coproduct (InL | InR)
> Gábor ? (LeftF | RightF)
> Andreas Either1 (Left1 | Right1)
> Sean Sum (InL | InR)
> Henning Sum no prefixes
>
>
> Unfortunately, there seems to be a preference for a new data type instead of a newtype wrapping for Either, which gives us three bike sheds to paint instead of one. I'm going to list some of the suggested alternatives here:
>
> > data Coproduct f g a = LeftF (f a) | RightF (g a)
> > data Sum f g a = InL (f a) | InR (g a)
> > data Either1 f g a = Left1 (f a) | Right1 (g a)
> > data Either f g a = Left (f a) | Right (g a) -- use qualification
>
>
> I like the Either1 naming, but only if it's a start of a new trend. In other words, that's a good choice only if it gains a consensus so that other higher-order types switch to the scheme in the future. If that doesn't happen, my second choice would be Sum (InL, InR).
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
More information about the Libraries
mailing list