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