leftToMaybe/rightToMaybe

[Dan Doel]

Here's another smart-ass remark, then: use lens and bifunctors. They
have great abstractions for these.

mapEither and mapPair are just two specializations of bimap. It also
has first and second which generalize mapFst, etc. And by the way,
everyone here (I think) has missed that you can also traverse these
things, but bifunctors also has that covered, with bitraverse.

The individual parts are applications of lenses, too. over _1 and over
_2 are mapFst and mapSnd. _1 and _2 function as traverseFst and
traverseSnd. For Either, there are prisms, _Left and _Right. over
_Left is mapLeft, over _Right is mapRight. has _Left is isLeft, has
_Right is isRight (apparently `is` was deemed too good to take; but
there's also isn't _Left). leftToMaybe is preview _Left. rightToMaybe
is preview _Right. _Left is traverseLeft. Etc. (fromLeft/Right is the
only one I can't cover well, but my knowledge of lens isn't
encyclopedic; the best I can come up with off the top of my head is
foldrOf _Left const).

I'm not really opposed to adding all these specialized functions to
data type modules. But you have to add a lot (far more than is even
called for here) to get all the functionality that you _already_ have
from a few general abstractions. And the latter translates to many
other types.

On Fri, Aug 9, 2013 at 2:52 AM, Andreas Abel <andreas.abel at ifi.lmu.de> wrote:
> It happens again and again on this list:  Someone request an innocent
> function on tuples or Either and after some initial discussion someone else
> writes "it is in Control.Arrow".  No offense intended, but to me "just use
> Control.Arrow.xxx" is a smart-ass comment in the line of "this is just a lax
> monoidal functor" I hear from category-theorists all the time.
>
> Arrows are on a level of abstraction that many Haskell programmers
> (including me) do not make use of and should *not* be forced to study just
> because they need an innocent function about tuples (or Either).
>
> I bet that most imports of Control.Arrow are to make up for an impoverished
> Data.Tuple, and proper arrow programming is the exception.
>
> Thus, I agree with Henning and David and many more that there is something
> wrong here.  mapEither, mapPair, mapFst, mapSnd and the like should be added
> to Data.Tuple and Data.Either, at the risk of duplicating stuff from
> Control.Arrow.  Otherwise, programmers will just roll their own version of
> these function again (which is duplication that comes at a cost) and
> additionally be alienated at the design of the Haskell libraries.
>
>
>
> On 08.08.13 4:26 PM, Henning Thielemann wrote:
>>
>>
>> On Thu, 8 Aug 2013, Erik Hesselink wrote:
>>
>>> On Thu, Aug 8, 2013 at 1:09 PM, Henning Thielemann
>>> <lemming at henning-thielemann.de> wrote:
>>>>
>>>>
>>>> On Thu, 8 Aug 2013, David Luposchainsky wrote:
>>>>
>>>>> On 2013-08-07 19:13, Erik Hesselink wrote:
>>>>>>>
>>>>>>>
>>>>>>> mapEither :: (l -> l') -> (r -> r') -> Either l r -> Either l' r'
>>>>>>> mapEither fl fr = either (Left . fl) (Right . fr)
>>>>>>
>>>>>>
>>>>>> This function is hidden in Control.Arrow as (+++).
>>>>>
>>>>>
>>>>> I didn't know about those functions, and it seems everything I
>>>>> wanted is
>>>>> in there somewhere. However, I'm not sure what to think of
>>>>> Control.Arrow, I've always (ab)used it as an extended Data.Tuple,
>>>>> and as
>>>>> of today probably for its Either API functions.
>>>>
>>>>
>>>> For me using the arrow functions as Data.Tuple and Data.Either utility
>>>> functions is abuse. Control.Arrow is meant to generalize (->). If you
>>>> call
>>>> maybeLeft and MaybeRight this is certainly not your intention.
>>>
>>>
>>> But the point of generalized functions is to use them in a specialized
>>> context, right?
>>
>>
>> I think the primary goal is to use them to write generic functions.
>>
>>> You can generalize mapEither in multiple ways: you can generalize
>>> (->), or you can generalize Either (getting bimap from the bifunctors
>>> package). I don't get why it's wrong to specialize the Arrow to (->)
>>> and use the functions on Eithers or tuples.
>>
>>
>> Why should someone care about Arrows if he only wants to process Either?
>>
>>> I do agree that they're hard to find.
>>
>>
>> For me this is a hint that there is something wrong.
>>
>> If I want to have a function mapEither and do not find it in
>> Data.Either, I might have the idea that it is subsumed by a more general
>> function somewhere else. In this case I would certainly think about a
>> generalization of Either, but not of (->).
>
>
>
> --
> Andreas Abel  <><      Du bist der geliebte Mensch.
>
> Theoretical Computer Science, University of Munich
> Oettingenstr. 67, D-80538 Munich, GERMANY
>
> andreas.abel at ifi.lmu.de
> http://www2.tcs.ifi.lmu.de/~abel/
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries