gmane.comp.lang.scala.debate

RE: right-biasing Either

Chris Marshall — 2012-05-18T10:02:19

I just don't get the position from the perspective of the types. Validation, fixed in its Failure type is an Applicative functor (which want to keep). It is also a Monad (which you don't). I recall someone saying something about types not lying
Chris

Date: Fri, 18 May 2012 19:25:05 +1000
Subject: Re: [scala-debate] right-biasing Either
From: tmorris< at >tmorris.net
To: tim.pigden< at >optrak.com
CC: oxbow_lakes< at >hotmail.com; scala-debate< at >googlegroups.com

Validation.flatMap should be a type error.

On May 18, 2012 4:49 PM, "Tim Pigden" <tim.pigden< at >optrak.com> wrote:

sorry Tony, what will be "fixed"?
Are you changing the behaviour of Validation significantly?

On 17 May 2012 23:09, Tony Morris <tmorris< at >tmorris.net> wrote:

On May 18, 2012 3:36 AM, "Chris Marshall" <oxbow_lakes< at >hotmail.com> wrote:

This will be fixed. Please assume it doesn't.

Re: right-biasing Either

Tony Morris — 2012-05-18T09:25:05

Validation.flatMap should be a type error.
 On May 18, 2012 4:49 PM, "Tim Pigden" <tim.pigden< at >optrak.com> wrote:

RE: right-biasing Either

Chris Marshall — 2012-05-18T08:59:47

I oppose its removal as well; Validation is quite clearly a Monad.

Re: right-biasing Either

Jason Zaugg — 2012-05-18T08:56:17

On Fri, May 18, 2012 at 10:49 AM, Chris Marshall
<oxbow_lakes< at >hotmail.com> wrote:

I added that method and oppose its removal.

-jason

RE: right-biasing Either

Chris Marshall — 2012-05-18T08:49:39

I'll assume by "fixed", you mean "deprecated, with a clear migration strategy"

Date: Fri, 18 May 2012 08:09:37 +1000
Subject: RE: [scala-debate] right-biasing Either
From: tmorris< at >tmorris.net
To: oxbow_lakes< at >hotmail.com
CC: scala-debate< at >googlegroups.com

On May 18, 2012 3:36 AM, "Chris Marshall" <oxbow_lakes< at >hotmail.com> wrote:

This will be fixed. Please assume it doesn't.

Re: right-biasing Either

Tim Pigden — 2012-05-18T06:49:28

sorry Tony, what will be "fixed"?
Are you changing the behaviour of Validation significantly?


On 17 May 2012 23:09, Tony Morris <tmorris< at >tmorris.net> wrote:

RE: right-biasing Either

Tony Morris — 2012-05-17T22:09:37

This will be fixed. Please assume it doesn't.

RE: right-biasing Either

Chris Marshall — 2012-05-17T17:36:52

Scalaz's Validation does have flatMap. 
Welcome to Scala version 2.9.2 (Java HotSpot(TM) Server VM, Java 1.6.0_18).Type in expressions to have them evaluated.Type :help for more information.
scala> import scalaz._; import Scalaz._import scalaz._import Scalaz._
scala> "1".success[Exception] flatMap (_.parseInt)res0: scalaz.Validation[Exception,Int] = Success(1)
Or...
scala> for {     | s <- "1".success[Exception]     | i <- s.parseInt     | }     | yield ires1: scalaz.Validation[Exception,Int] = Success(1)
It just doesn't have a "default" implicit monad (viewable by the lack of >>=)
scala> "1".success[Exception] >>= (_.parseInt)<console>:14: error: could not find implicit value for parameter b: scalaz.Bind[[Î±]scalaz.Validation[Exception,Î±]]              "1".success[Exception] >>= (_.parseInt)                                     ^

...unless you import it, of course:
scala> import Validation.Monad._import Validation.Monad._
scala> "1".success[Exception] >>= (_.parseInt)res3: scalaz.Validation[Exception,

Re: right-biasing Either

Ivan Todoroski — 2012-05-17T15:36:48

It's also very similar to Lift's Box class:

http://www.assembla.com/spaces/liftweb/wiki/Box

So there is at least one precedent of someone needing a "three-state 
Option" badly enough to create it and use it in their framework.

Anyway, I just wanted to mention that it seems be a commonly needed 
pattern, I don't know if it has much bearing on the discussion about 
right-biasing Either (of which I have no opinion one way or another).

Re: right-biasing Either

Rex Kerr — 2012-05-17T15:32:14


Correct--isomorphic, but without the awkwardness of nested containers.



This requires you to load your Lefts with Options, which is a bit of a
pain, but yes, at least filter would work.



I'm not sure they're terribly useful as is, so I'd support that anyway.



The Try[U] apply method transparently catches exceptions so flatMap is
consistent.  Collect is the only odd-man-out that I saw.  (Well, and
filter; if your predicate throws an exception, you're out of luck.)

I agree that catching Throwable instead of Exception is dangerous.  That is
almost never the right thing to do.  I don't suppose we can change that,
though, because I bet Twitter relies upon it somewhere.  I would much
prefer if we could change it to only catch Exception (or to re-throw
ControlThrowable at least--that would be okay, wouldn't it?).

  --Rex

Re: right-biasing Either

Jason Zaugg — 2012-05-17T15:04:12

That looks quite useful. Naming the constructors is probably the hardest part :)

If I understand it correctly, it's isomorphic to Either[Option[A], B],
which is nice in that it allows for a useful filter method.

Perhaps we could take a similar approach for Either:

class Either[A, B] {
  def filter[AA](f: B => Boolean)(implicit ev: A =:= Option[AA]):
Either[A, B] =
     this match {
        case l < at > Left(_) => l
        case r < at > Right(b) => if (f(b)) r else Left(None)
     }

  // scalaz style
  def filter[AA](f: B => Boolean)(implicit M: Monoid[A]): Either[A, B]
= this match {
     case l < at > Left(_) => l
     case r < at > Right(b) => if (f(b)) r else Left(M.zero)
  }
}

I would suggest to deprecate/rename the current filter methods in left
and right projection first.


Try is a different beast altogether, I think its transparent exception
handling is dangerous and currently inconsistent. See my comments here
[1]

-jason

[1] https://github.com/scala/scala/commit/7d206f3c73#src/library/scala/util/Try.scala

Re: right-biasing Either

Rex Kerr — 2012-05-16T20:10:39

I propose this as an alternative, with more favorable use characteristics
than Try or right-biased Either.  The naming ("Has") is a little quirky
because I was trying to avoid using any existing names.

Either is an awkward fit because of the clumsiness of the isomorphism
between Option[X] and Either[Unit,X]; to get around this, there are three
subclasses: Yes[X], Plea[T], and No.
  Yes[X] - the success type, like Right[X] or Some[X]
  Plea[T] - an excuse for why things didn't work, like Left[T]
  No - it didn't work and you have no idea why, like None

Has is _very strongly right-biased_ (yes-biased).  Although a subset of
methods are defined for Plea, if you want to work in left-biased mode
(plea-biased), use swap.

Code is here: http://pastebin.com/TV1NKy5b

Here's a short example of one way to use it:

  def negativeParse(s: String) = {
    for (d <- Has.catchAll(s.toDouble) if !d.isNaN) yield -d
  }

I'm not suggesting that we turn Either into this, but I think something
like this is the level to which

Re: right-biasing Either

Matthew Pocock — 2012-05-15T21:38:15


Perhaps this is where I am confused then. Every example of right-biassed
Either I've seen is framed in terms of success and failure. I have seen
zero examples of it being used in some other way. Perhaps a compelling
example of using a right-biassed Either where left doesn't model failure
and right success would convince me that this is a worthy change.

M

Re: right-biasing Either

Matthew Pocock — 2012-05-15T21:35:53

I agree another data type is warranted, but with careful consideration,
Yeah, I agree with both your points. Conflation is a poor-man's isomorphism.

Re: right-biasing Either

Tony Morris — 2012-05-15T21:35:19

I have not seen in the proposal where Either now becomes biased toward
failure or success. Right-biasing Either does not cause this.

Re: right-biasing Either

Matthew Pocock — 2012-05-15T21:33:51

I don't expect you to take anything on board on the basis of my strong
belief ;) However, names are important to the average coder though, and
standard libraries are intended to be understandable to and used by the
average coder and the casual user.

Types are not where coding begins and ends. There is a gap to be bridged
between the code and the coder's understanding. Names are part of this
bridge.

Re: right-biasing Either

Tony Morris — 2012-05-15T21:32:56

Scalaz does this with Validation, but it is not a monad and so does not
have flatMap.

I agree another data type is warranted, but with careful consideration,
we could unify them all with some nice library design with implicits --
just sayin'!

Re: right-biasing Either

Tony Morris — 2012-05-15T21:30:19

I should imagine the proposal is to throw all that is on RightProjection
onto Either and call it good.

And if I could have my way, there would be a crap-ton more useful
libraries on there too, but I don't think that's the proposal.

Re: right-biasing Either

Tony Morris — 2012-05-15T21:27:42

It perhaps should be noted that right-biasing Either and the idea of
using Either for error-handling should not be conflated. Either says
nothing about error-handling -- it is trivial summation and nothing
more. That someone might use it in its specialised form or perhaps even
specialise it one type argument (Try), is beside the point of the need
to right-bias Either. We should not conflate these things in discussion.


On 16/05/12 03:14, Simon Ochsenreither wrote:

Re: right-biasing Either

Tony Morris — 2012-05-15T21:24:40

Yes.

Moreover you'd want Option[T] <=> Either[Unit, T] where <=> denotes
bijection. Rather than an implicit, I'd simply prefer library support
for isomorphisms -- much easier to work with then.

In any case, I think that is all beside the point of right-biasing Either.

Re: right-biasing Either

Tony Morris — 2012-05-15T21:22:48

I think you mean Either[Unit, T] which is the isomorphism you are
alluding to.

Either[Nothing, T] ~= T