Diagonalization/ dupe for monads and tuples?

Carter Schonwald carter.schonwald at gmail.com
Sat Sep 26 18:45:38 UTC 2020


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.

I’d genuinely appreciate it if folks actually address or think about the
generalizations that are the start of this thread please! :)

On Sat, Sep 26, 2020 at 2:55 AM George Wilson <george at wils.online> wrote:

> 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 at 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 at 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 at 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 at gmail.com> wrote:
>
> >>>
>
> >>> On Thu, Sep 17, 2020 at 5:59 PM Jon Purdy <evincarofautumn at 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 at haskell.org
>
> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> >>>
>
> >>>
>
> >>> _______________________________________________
>
> >>>
>
> >>> Libraries mailing list
>
> >>>
>
> >>> Libraries at haskell.org
>
> >>>
>
> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> >>>
>
> >> _______________________________________________
>
> >> Libraries mailing list
>
> >> Libraries at haskell.org
>
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> >
>
> >
>
> >
>
> > --
>
> > Markus Läll
>
> > _______________________________________________
>
> > Libraries mailing list
>
> > Libraries at haskell.org
>
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200926/4956d27e/attachment.html>


More information about the Libraries mailing list