Proposal: merge Data.Functor.Coproduct into transformers
leather at cs.uu.nl
Tue Dec 11 14:03:47 CET 2012
On Tue, Dec 11, 2012 at 1:42 PM, wren ng thornton wrote:
> On 12/11/12 7:27 AM, Mario Blazevic wrote:
>> On Tue, Dec 11, 2012 at 5:29 AM, Edward Kmett wrote:
>>> 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
>>> I agree that I wouldn't want to add functions named 'left' and 'right',
>>> moving to a data type rather than a newtype seems reasonable.
>>> data Coproduct f g a = LeftF (f a) | RightF (g a)
>>> would be a nice color for the bikeshed?
These also work for Sum. ;)
I hesitate to suggest another alternative, but if folks are displeased
> with those names, there's always the tried and true InL/InR or InjL/InjR.
> But given the precedent of Either, I think LeftF/RightF have a nice ring to
At first, I couldn't think of a standard library precedent for using L and
R as left and right, but then I remembered ViewL/ViewR in
Of all the above, InL/InR are my favorites, since they pun "in" for
elimination and "inject" for introduction (or you could think "put in").
Nah, those constructor names are dumb. I prefer Shaun's
>> data Sum f g a = SumLeft (f a) | SumRight (g a)
> -1. What happened to the vaunted brevity? I type out the names of data
> constructors far more often than the names of type constructors. And those
> data constructor names are obnoxiously long for something as basic as a
> functor coproduct.
The verbosity of the Data.Functor.* modules in transformers is a general
complaint of mine. But it's there already, so I was thinking we should
match the style. Otherwise, I'd be happy with just L/R. ;)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libraries