It should be right-biased, like it was back at the start.
Consensus failed due to a derailing with irrelevant discussion e.g. exceptions, errors. We should try not to do that. Either is a binary functor denoting summation, nothing more. Talk of exceptions are orthogonal to this matter. Oh, almost forgot, I also heard that Either is a glorified tuple, but that might be nonsense.
Yes. Either does not have filter, because it does not have a unit constructor. It should never have existed. It's a dirty, stinking hack.
The existing filter might continue to exist, as _.toOption andThen _.filter(p), but it is currently misnamed.
The inability to filter Either is unavoidable and always has been. It has no unit constructor. This fact of the matter is distinct, orthogonal and not relevant to the necessity to right-bias.
I don't see any way to let Either do this. This suggest to me that Either is simply the wrong concept to use in for-comprehensions. If it's the wrong concept to use it for-comprehensions, it doesn't much matter whether it's right-biased or not, IMO. You need something isomorphic to Either[Option[L],R] (assuming right-bias).
On Saturday, June 16, 2012 8:33:48 AM UTC-4, Rex Kerr wrote:I don't see any way to let Either do this. This suggest to me that Either is simply the wrong concept to use in for-comprehensions. If it's the wrong concept to use it for-comprehensions, it doesn't much matter whether it's right-biased or not, IMO. You need something isomorphic to Either[Option[L],R] (assuming right-bias).
Either is exactly the kind of thing that should be usable with a monad comprehension. Maybe what this rather points to is that this expression is currently desugared incorrectly:
for { (a, b) <- either } yield a
for { (a, b) <- either } yield a
It should desugar to something like:
either.map { case (a, b) => a }
x.filter(_ => true) == x
x.filter(_ => false) == Monoid.zero
These are reasonable expectations of filter. Things with filter can be achieved with a monad with plus/empty. Not all monads have this. Notice that Function1 had map +flatMap but not filter. This is because it cannot exist, like for Either. Because not all monads have plus/empty. Some monads do not have filter. This is fine, mundane, common.
This fact is all completely beside the point of the necessity to right-bias Either. I wish this topic wasn't derailed each time it is brought up. Perhaps we can have a "I really wish Either had filter, what a stupid universe" thread or something.
x.filter(_ => true) == x
x.filter(_ => false) == Monoid.zeroThese are reasonable expectations of filter. Things with filter can be achieved with a monad with plus/empty. Not all monads have this. Notice that Function1 had map +flatMap but not filter. This is because it cannot exist, like for Either. Because not all monads have plus/empty. Some monads do not have filter. This is fine, mundane, common.
This fact is all completely beside the point of the necessity to right-bias Either.
I give up. Godspeed.
then I don't care what bias Either has. Likewise with fold. In fact, if I am actually dealing with a symmetric case, then I'd rather _not_ have bias because e.left.map(f) makes it more obvious what is going on than the tempting e.swap.map(f).swap with a right-biased either, and the latter also poses risks of forgetting to swap back.
The only time I've missed the right-bias on either is when using for comprehensions. And then, Either doesn't play nicely anyway _in part precisely because it does not have plus/empty_.
 for (rt <- e; x <- m.get(rt)) yield x  // Doesn't and can't work
 for (rt <- e; x <- m.get(rt).toRight("not found")) yield x // Could work
 for (rt <- e; x <- m.get(rt) if x>0) yield x // Can't work
 for (rt <- e; x <- m.get(rt).filter(_>0).toRight("nope")) yield x
 // Why even use for?
Therefore, although I don't _strongly_ object to changing Either, I do strongly encourage us to consider whether a right-biased Either is a good enough solution for certain things (e.g. error handling), and if we had something that _was_ a good enough solution for error handling whether we would still want Either to be right biased.
In my case the answers are "no" and "no". Other people may have different answers. But I'm puzzled by the apparent reluctance of people to _even answer this question_. It seems like there's too much enthusiasm for rushing into a partial fix to a problem that really warrants a complete fix, and which Either cannot theoretically deliver.
Here's yet another branch, this time supporting for-comprehensions
containing 'if' and refutable pattern-matching:
https://github.com/robcd/scala-either-proj-map-returns-proj/tree/add_right-bias_2-10_withFilter
This one adds a withFilter to Either, that uses implicit conversions
to obtain a Left when the predicate is false.
Rob