Diagonalization/ dupe for monads and tuples?

[David Feuer]

Makes sense to me!

On Thu, Sep 17, 2020, 12: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.
>
> 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
>>
> _______________________________________________
> 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/938cf617/attachment.html>