On Sun, Jun 24, 2012 at 6:33 PM, Rob Dickens <
robcdickens <at> gmail.com> wrote:
>> ...
>> Left(x) <- doSomething
>> Right(y) <- doSomethingElse(x)
>> ...
>> should work, once the 2.10 compiler is fixed for this kind of pattern
>
> Hm.. maybe not. Unfortunately, it looks to me as though 'refutable'
> pattern-matching in for-comprehensions just can't be supported for
> Either (not having a 'None' subclass or withFilter method). Unless
> Josh has thought of something...
>
> Rob
>
> On Tue, Jun 19, 2012 at 1:12 PM, Rob Dickens <
robcdickens <at> gmail.com> wrote:
>> Josh, Looking at just your first snippet, using the proposed Either*,
>> the following should work, once the 2.10 compiler is fixed** for this
>> kind of pattern (as it already is for tuple patterns):
>>
>> type EInner = Either[String, Int]
>> type EOuter = Either[String, EInner]
>> def doSomething: EOuter = Right(Left("er"))
>> def doSomethingElse(s: String): EOuter = Right(Right(s.toInt))
>>
>> val x: EOuter =
>> for {
>> Left(x) <- doSomething
>> Right(y) <- doSomethingElse(x)
>> } yield Left(y.toString)
>>
>> It that's not what you had in mind (which I fear it isn't), please
>> give us a more complete version!
>>
>> * right-biased, retains unbiased capability (via lp, rp methods), no filter
>> ** error ( > doSomething): value filter is not a member of EOuter
>>
>> Rob
>>
>> On Mon, Jun 18, 2012 at 11:19 PM, Josh Suereth <
joshua.suereth <at> gmail.com> wrote:
>>> We could go strange on the Either front:
>>>
>>>
>>> val x: Either[A,B] =
>>> for {
>>> Left(x) <- doSomething
>>> Right(y) <- somethingElse(x)
>>> } yield Left(y)
>>>
>>> has this already been negated as a bad idea?
>>>
>>> What I think would be nice to fix is:
>>>
>>> val x: Either.LeftProjection[A,B] =
>>> for {
>>> x <- doSomething.left
>>> y <- doSomethingElse(x).right
>>> } yield y
>>>
>>>
>>> or just:
>>>
>>> val x : Either[A,B] =
>>> (for {
>>> a <- doA.left
>>> b <- doB(a)
>>> c <- doC(b)
>>> } yield c).toEither
>>>
>>>
>>>
>>> Am I missing something?
>>>
>>> On Mon, Jun 18, 2012 at 6:14 PM, Tony Morris <
tonymorris <at> gmail.com> wrote:
>>>>
>>>> I give up. Godspeed.
>>>>
>>>> On Jun 19, 2012 4:11 AM, "Rex Kerr" <
ichoran <at> gmail.com> wrote:
>>>>>
>>>>> On Sat, Jun 16, 2012 at 10:53 PM, Tony Morris <
tonymorris <at> gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> 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.
>>>>>
>>>>> Completely agreed.
>>>>>
>>>>>>
>>>>>> This fact is all completely beside the point of the necessity to
>>>>>> right-bias Either.
>>>>>
>>>>> Completely disagreed. I use Either outside of for-comprehensions and
>>>>> have never missed the right bias in contexts where I do not care if I have a
>>>>> filter or not. To me, this is the key issue. If I am going to
>>>>> e match {
>>>>> case Left(x) => ...
>>>>> case Right(x) => ...
>>>>> }
>>>>> 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?
>>>>>
>>>>> The reason I'm consistently lukewarm to negative about right-biasing
>>>>> Either is because Either is the wrong tool for the job for the most common
>>>>> uses of a right-biased union monad.
>>>>>
>>>>> For being right-biased, either
>>>>> - Is misnamed ("either" doesn't suggest bias)
>>>>> - Isn't good for easy error handling (no filter)
>>>>> - Can't have full support within for-comprehensions (unless we change
>>>>> those also)
>>>>> - Historically wasn't that way
>>>>> all of which recommends against the change.
>>>>>
>>>>> 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.
>>>>>
>>>>> --Rex
>>>>>
>>>>> P.S. Actually, I think "else" statements in for comprehensions would
>>>>> adequately empower right-biased Either to be an adequate solution. You
>>>>> would need to desugar
>>>>> for (x <- y if (p) else g) yield x
>>>>> and
>>>>> for (x <- y else g)
>>>>> into a conditional on p and y.isEmpty, respectively, inside an
>>>>> appropriate method. Then Either would be as full-functioned as Option (and
>>>>> could enable some nice tricks with collections).
>>>>> def flatDefault(p: A=>Boolean, default: => Either[A,B]): Either[A,B] =
>>>>> ...
>>>>> or the corresponding non-flat version (i.e. default: => B) would probably
>>>>> do the trick, but I haven't worked through all possible cases to make sure
>>>>> it would always do the right thing.
>>>>>
>>>
RSS Feed