I support adding both

  a -> (a,a)

and

  Either a a -> a



dedup doesn't seem right to me because there aren't two things, so I

submit the name: whichever.

  whichever :: Either a a -> a

Just give me whichever one's there.



When I see the name fromEither, I think of the type

  (e -> a) -> Either e a -> a

so I am against the name fromEither being used for Either a a -> a



I'm not fully satisfied by either pair of  diag,codiag  /  dup,dedup

but I could live with them.

My preference is dup/whichever



Cheers,

George





On Fri, 25 Sep 2020 at 22:56, Markus Läll <markus.l2ll@gmail.com> wrote:

>

> How about `eitherId` for the `Either a a -> a`? I.e one usually does `either id id` to extract either value.

>

> `fromEither` isn't a bad idea, but it's long.

>

> On Wed, Sep 23, 2020 at 3:49 PM Carter Schonwald <carter.schonwald@gmail.com> wrote:

>>

>> Rob,

>> 1) your foldEither is way better and I love it.

>>

>> 2) this is a way more pleasing Avenue of design for the tuple and either combinators ! Thank you for sharing this great little exposition.

>>

>> On Wed, Sep 23, 2020 at 8:20 AM Rob Rix via Libraries <libraries@haskell.org> wrote:

>>>

>>> TL;DR: maybe we can think of this as combining disjoint empty & non-empty cases of folds.

>>>

>>> Every time I’ve wanted to define something like this I’ve found myself dissatisfied because of this asymmetry.

>>>

>>> Looking at it from another angle, I frequently encounter a vaguely similar situation with folds: given some collection which can be empty or non-, I want to fold over it with a function if non-empty, or return a default value if empty:

>>>

>>> foldr1OrDefault :: Foldable t => (a -> a -> a) -> a -> t a -> a

>>> foldr1OrDefault f z t

>>>   | null t    = z

>>>   | otherwise = foldr1 f t

>>>

>>>

>>> This is a bit like Control.Lens.Fold.foldBy in lens, except that the combining function f does not receive z at any point. Quite useful when you have a Semigroup but not a Monoid, or when you otherwise want to treat the empty case specially.

>>>

>>> fromMaybe is a special case of this function, without the conceit of pretending that Maybe can hold multiple values. I’ve sometimes involved Maybe in this construction for just that reason when e.g. a is a Semigroup:

>>>

>>> fold1Maybe :: (Foldable t, Semigroup a) => t a -> Maybe a

>>> fold1Maybe = foldMap Just

>>>

>>> fold1OrDefault :: (Foldable t, Semigroup a) => a -> t a -> a

>>> fold1OrDefault z = fromMaybe z . foldMap Just

>>>

>>>

>>> (All of these names are intentionally bad because I don’t want to propose adding these functions anywhere just yet.)

>>>

>>> For Either (and These for that matter), a full generalization also has to deal with the extra information in the null case, i.e. Either b a would need (b -> a) instead of a:

>>>

>>> fromEither :: (b -> a) -> Either b a -> a

>>> fromEither f = either f id

>>>

>>>

>>> I’m surprised about once every six months that this doesn’t exist (and then surprised again when consulting the types that fromLeft/fromRight aren’t either this *or* analogous to fromJust).

>>>

>>> All of which is to say, I think I would prefer to have the generality of this fromEither to the a -> Either a a -> a version, but it’d be nice to figure out a way to see it as a fold, too. Maybe the Bifoldable1 instance for Either has something to contribute here?

>>>

>>> Rob

>>>

>>> On Sep 17, 2020, at 1:13 PM, Philip Hazelden <philip.hazelden@gmail.com> wrote:

>>>

>>> On Thu, Sep 17, 2020 at 5:59 PM Jon Purdy <evincarofautumn@gmail.com> wrote:

>>>>

>>>> { fromMaybe, fromLeft, fromRight, fromEither, fromThese, fromDynamic, … } extracts “the” value out of a { Maybe, These, Dynamic, … } with a suitable default if “it” isn’t present.

>>>

>>>

>>> Hm. A weird thing about fromEither compared to (I think) all the rest of these, is that the type of the Either isn't fully general. That is, fromLeft and fromRight take an `Either a b`; fromThese takes a `These a b`. But the proposed `fromEither` takes an `Either a a`.

>>>

>>> This maybe isn't a big deal. Just seemed worth noting.

>>>

>>>

>>> _______________________________________________

>>> Libraries mailing list

>>> Libraries@haskell.org

>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

>>>

>>>

>>> _______________________________________________

>>>

>>> Libraries mailing list

>>>

>>> Libraries@haskell.org

>>>

>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

>>>

>> _______________________________________________

>> Libraries mailing list

>> Libraries@haskell.org

>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

>

>

>

> --

> Markus Läll

> _______________________________________________

> Libraries mailing list

> Libraries@haskell.org

> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries