Diagonalization/ dupe for monads and tuples?

[Jon Purdy]

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

These functions map a type onto the smallest product type that can
represent the union of its possible values, taking defaults as needed to
make the result total. They seem asymmetric at first glance because the
structures of the input types differ, but they’re all doing the same thing.

More to the point, anecdotally, I see Haskell beginners often reaching for
accessor functions like ‘head’ and ‘fromJust’ before they’ve internalised
pattern matching. They do use total combinators like ‘fromMaybe’ if
available (and if they’re aware of them), because these combinators are
more convenient than ‘if isJust … then fromJust … else …’, and they only
happen to be safer incidentally. It’s the familiar “get value or default”
pattern, if they’ve programmed before, nothing to do with totality. So it
seems sensible to me to plug the hole in the taxonomy.

On Thu, Sep 17, 2020, 6:34 AM Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> I’m not sure how fromMaybe relates here.  Could someone explain?
>
> For the anti-categorical folks who dislike codiag or related names like
> trace (in linear algebra trace is the sum of the diagonal of a matrix as a
> scalar, an apt analogy I think), another name that I think is descriptive
> is collapse
>
>
> Names bandied about so far:
>
> Dedup
> Codiag
> Fromeither
>
> Things I mentioned above : trace and collapse
>
> Zooming out though, this operation is equiv to “either id id”, so I don’t
> really see how inventing a new name for this specific tiny snippet really
> helps anyone.
>
>
> On Thu, Sep 17, 2020 at 8:54 AM chessai <chessai1996 at gmail.com> wrote:
>
>> My instinct about fromEither's type was the same as Carter's, and I had
>> to remind myself of fromMaybe. I like the name fromEither overall. Seems to
>> fit well with precedent and is straightforward enough.
>>
>> On Thu, Sep 17, 2020, 07:45 Oliver Charles <ollie at ocharles.org.uk> wrote:
>>
>>> You may wish to compare with fromMaybe then, which probably also doesn't
>>> have the type you'd expect :) The type you have there is more like bifoldMap
>>>
>>> On Thu, 17 Sep 2020, at 1:42 PM, Carter Schonwald wrote:
>>>
>>> I’d expect fromEither to be
>>> Either a b -> (a-> c )-> (b-> c) -> c
>>>
>>> Nothing about the name fromEither is suggestive of the Either a a type
>>>
>>> On Thu, Sep 17, 2020 at 3:45 AM Oliver Charles <ollie at ocharles.org.uk>
>>> wrote:
>>>
>>>
>>> Regardless of having a more abstract version, I'm +1 on Jon's
>>> suggestion, and those names. fromEither is something I have reached for
>>> many many times and been surprised it's not within arms reach.
>>>
>>> On Thu, 17 Sep 2020, at 7:16 AM, Jon Purdy wrote:
>>>
>>> I’m strongly for these:
>>>
>>> Data.Tuple.dup :: a → (a, a)
>>>
>>> Data.Either.fromEither :: Either a a → a
>>>
>>>
>>> _______________________________________________
>>>
>>>
>>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200917/19d90e21/attachment.html>