add \/ alias for either function

[srghma]

just like this is done for Tuple constructor in Data.Tuple.Nested

https://github.com/purescript/purescript-tuples/blob/v5.1.0/src/Data/Tuple/Nested.purs#L31-L31

[hdgarrood]

At first I was like "maybe let's not add more operators" but this is actually super neat, since it lets you match on nested eithers rather nicely:

f :: (Int \/ String \/ Boolean) -> String
f = show \/ identity \/ if _ then "yes" else "no"

I would support adding this as long as it has some documentation. 👍

[srghma]

@hdgarrood tnx, what documentation would you propose? We can add the example you just posted or example with $

[hdgarrood]

What do you mean by the example with $? The one I posted works for me, although it would be good to add examples of calling it with values from each “branch” of the nested Either to better indicate what it does in case it’s not immediately clear to the reader.

[srghma]

I've meant something like

calculationResult :: IO Int
calculationResult = throwError /\ pure $ Left "Error during calculation"

but your example is better

[srghma]

@hdgarrood could you add the documentation note yourself? I'm afraid I will make it wrong

[srghma]

@hdgarrood I have added comment, dont know why test fails

[hdgarrood]

I think we're running into purescript-contrib/pulp#392. I've just published pulp v15.0.0 with a fix so hopefully updating will be enough here.

[hdgarrood]

Sorry for the delay. How about this for the comments:

The `\/` operator alias for the `either` function allows easy matching on nested Eithers. For example, consider the function

    f :: (Int \/ String \/ Boolean) -> String
    f (Left x) = show x
    f (Right (Left y)) = y
    f (Right (Right z)) = if z then "Yes" else "No"

The `\/` operator alias allows us to rewrite this function as

    f :: (Int \/ String \/ Boolean) -> String
    f = show \/ identity \/ if _ then "Yes" else "No"

[srghma]

@hdgarrood done

[hdgarrood]

Thanks!

[srghma]

@hdgarrood or @hdgarrood or @natefaubion could someone merge it

it's not being merged without reason for so long

[hdgarrood]

Sorry, but you don't get to set the timescales on these things. Our policy is that changes to the core libraries need to be reviewed by 2 people, and our attention is more directed towards the upcoming v0.14.0 release at the moment.

[srghma]

ok, at least now I know the reason

[JordanMartinez]

@srghma Could you fix the merge conflicts? I think we can merge soon after that.

[srghma]

@hdgarrood done