<div dir="auto">Dup and whichever for the  tuple and either sound fine, as long as there’s a reference to diag and codiag or whatever names we settle on for the general versions that are the actual subject of this thread. </div><div dir="auto"><br></div><div dir="auto">I’d genuinely appreciate it if folks actually address or think about the generalizations that are the start of this thread please! :) </div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Sep 26, 2020 at 2:55 AM George Wilson <george@wils.online> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I support adding both<br><br>  a -> (a,a)<br><br>and<br><br>  Either a a -> a<br><br><br><br>dedup doesn't seem right to me because there aren't two things, so I<br><br>submit the name: whichever.<br><br>  whichever :: Either a a -> a<br><br>Just give me whichever one's there.<br><br><br><br>When I see the name fromEither, I think of the type<br><br>  (e -> a) -> Either e a -> a<br><br>so I am against the name fromEither being used for Either a a -> a<br><br><br><br>I'm not fully satisfied by either pair of  diag,codiag  /  dup,dedup<br><br>but I could live with them.<br><br>My preference is dup/whichever<br><br><br><br>Cheers,<br><br>George<br><br><br><br><br><br>On Fri, 25 Sep 2020 at 22:56, Markus Läll <<a href="mailto:markus.l2ll@gmail.com" target="_blank">markus.l2ll@gmail.com</a>> wrote:<br><br>><br><br>> How about `eitherId` for the `Either a a -> a`? I.e one usually does `either id id` to extract either value.<br><br>><br><br>> `fromEither` isn't a bad idea, but it's long.<br><br>><br><br>> On Wed, Sep 23, 2020 at 3:49 PM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>> wrote:<br><br>>><br><br>>> Rob,<br><br>>> 1) your foldEither is way better and I love it.<br><br>>><br><br>>> 2) this is a way more pleasing Avenue of design for the tuple and either combinators ! Thank you for sharing this great little exposition.<br><br>>><br><br>>> On Wed, Sep 23, 2020 at 8:20 AM Rob Rix via Libraries <<a href="mailto:libraries@haskell.org" target="_blank">libraries@haskell.org</a>> wrote:<br><br>>>><br><br>>>> TL;DR: maybe we can think of this as combining disjoint empty & non-empty cases of folds.<br><br>>>><br><br>>>> Every time I’ve wanted to define something like this I’ve found myself dissatisfied because of this asymmetry.<br><br>>>><br><br>>>> 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:<br><br>>>><br><br>>>> foldr1OrDefault :: Foldable t => (a -> a -> a) -> a -> t a -> a<br><br>>>> foldr1OrDefault f z t<br><br>>>>   | null t    = z<br><br>>>>   | otherwise = foldr1 f t<br><br>>>><br><br>>>><br><br>>>> 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.<br><br>>>><br><br>>>> 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:<br><br>>>><br><br>>>> fold1Maybe :: (Foldable t, Semigroup a) => t a -> Maybe a<br><br>>>> fold1Maybe = foldMap Just<br><br>>>><br><br>>>> fold1OrDefault :: (Foldable t, Semigroup a) => a -> t a -> a<br><br>>>> fold1OrDefault z = fromMaybe z . foldMap Just<br><br>>>><br><br>>>><br><br>>>> (All of these names are intentionally bad because I don’t want to propose adding these functions anywhere just yet.)<br><br>>>><br><br>>>> 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:<br><br>>>><br><br>>>> fromEither :: (b -> a) -> Either b a -> a<br><br>>>> fromEither f = either f id<br><br>>>><br><br>>>><br><br>>>> 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).<br><br>>>><br><br>>>> 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?<br><br>>>><br><br>>>> Rob<br><br>>>><br><br>>>> On Sep 17, 2020, at 1:13 PM, Philip Hazelden <<a href="mailto:philip.hazelden@gmail.com" target="_blank">philip.hazelden@gmail.com</a>> wrote:<br><br>>>><br><br>>>> On Thu, Sep 17, 2020 at 5:59 PM Jon Purdy <<a href="mailto:evincarofautumn@gmail.com" target="_blank">evincarofautumn@gmail.com</a>> wrote:<br><br>>>>><br><br>>>>> { fromMaybe, fromLeft, fromRight, fromEither, fromThese, fromDynamic, … } extracts “the” value out of a { Maybe, These, Dynamic, … } with a suitable default if “it” isn’t present.<br><br>>>><br><br>>>><br><br>>>> 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`.<br><br>>>><br><br>>>> This maybe isn't a big deal. Just seemed worth noting.<br><br>>>><br><br>>>><br><br>>>> _______________________________________________<br><br>>>> Libraries mailing list<br><br>>>> <a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br><br>>>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br><br>>>><br><br>>>><br><br>>>> _______________________________________________<br><br>>>><br><br>>>> Libraries mailing list<br><br>>>><br><br>>>> <a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br><br>>>><br><br>>>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br><br>>>><br><br>>> _______________________________________________<br><br>>> Libraries mailing list<br><br>>> <a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br><br>>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br><br>><br><br>><br><br>><br><br>> --<br><br>> Markus Läll<br><br>> _______________________________________________<br><br>> Libraries mailing list<br><br>> <a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br><br>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br><br></blockquote></div></div>