Validation/Either/etc

[Tony Morris]

Hello,
Like many of you, I use Scalaz in production code. So, when Jason posted
to the [scala-user] list regarding a right-bias for scala.Either and the
discussion was derailed (twice) stunting progress, this had an adverse
impact on my what would be me future everyday work. Possibly for you too.

Although I am the original author of scala.Either, it is *nothing* like
how I would have written it if the goals of Scala were more aligned with
my thoughts on library design. That was in 2008. I guess I am not L3
enough or something. It's not the point.

The coming together of a lot of events recently compelled me to suck it
up and write my own (A \/ B) data type on a scalaz branch, then do away
with scala.Either so I don't really have to acknowledge its existence
anymore.

I am also tidying up EitherT and I am currently tidying up Validation. I
am aiming for consistency where appropriate and also the appropriate
distinctions. I strongly believe that Validation should not have a monad
(and therefore, ValidationT should not exist). I have changed
scalaz.Cozip and scalaz.Free to use scalaz.\/ instead of scala.Either
and I have made other smaller changes. However, I'd like decent library
support in the event that a user wants the behaviour that was previously
provided by the Validation monad.

I expect to have this finished soon mostly because it is compelled by
the production code that I am writing, so I was wondering what others'
thoughts were on this. In particular, any possible requests on the
design and whether we could/should release this work in the upcoming
scalaz7 (I am not particularly happy with the current state of affairs
here -- don't know about you).

--
Tony Morris
http://tmorris.net/

[Chris Marshall]

Can we have a really simple way to switch between validations and eithers for when we want the validation monad then? e.g either.v, validation.e

Chris

--
You received this message because you are subscribed to the Google Groups "scalaz" group.
To post to this group, send email to sca...@googlegroups.com.
To unsubscribe from this group, send email to scalaz+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scalaz?hl=en.

[Tony Morris]

You mean when you want the X => Either[E, X] monad? There is no such thing as a monad for X => Validation[E, X]. Yes, we can.

[Chris Marshall]

I would argue that "There is no such thing as a monad for .." is not correct in the sense that those of us using scalaz6 have been using the one provided in the library. I believe we have had this exchange before

Chris

[Tony Morris]

I don't recall the discussion.

Whatever you have been using is not a monad. The fact that it looks
otherwise is the problem to which I object.

[Chris Marshall]

Unfortunate naming choice then :-s

scala> import scalaz._; import Scalaz._

import scalaz._

import Scalaz._

scala> import Validation.Monad._

import Validation.Monad._

scala> "1".success[Exception] >>= (_.parseInt)

res0: scalaz.Validation[Exception,Int] = Success(1)

[Tony Morris]

I agree, hence its removal.

[Richard Wallace]

I've been confused by this argument before. I think I've come to
understand why. As I understand things, the following property should
hold for all values of x and y belonging to a type M for which a valid
Monad instance is defined.

x <|*|> y === x >>= (a => y map ((a, _)))

Validation fails this property when both x and y are failures because
on the left the result will be the failure of y appended to the
failure of x and on the right the result will be just the failure of
x. Is this reasoning correct?

If so, then I agree that Validation cannot have a valid Monad instance
defined and that ValidationT should not exist.

This does make me a bit sad because I have some code that I was rather
hoping to cleanup with ValidationT. I also have a few places where I
do want the first failure and not to have failures accumulated (think
validating a form field and checking that it is an integer and then
that the integer is in a given range, you don't want to and cannot do
that using ap), so I use flatMap. I agree this can be done by
converting to Either, doing the checks, then converting back to
Validation (if necessary), but think this operation should remain
available on Validation even if we call it something other than
flatMap (maybe flatMapV?).

[Richard Wallace]

Just wanted to add that I'm more than happy to put things in scalaz
that are meant as replacements for stdlib counterparts. I'd really
like to see good Map and Set replacements - wasn't there someone
working on these?

[Tony Morris]

Yeah many times I have needed a decent Map/Set implementation for Scala,
only to concede the point so that I could carry on with whatever I was
doing. One day I might get annoyed enough to dive in.

I think Gary Pampara was working on a port of Data.Map, don't know about
sets.

[Gary Pampara]

I have a basic Map impl here:
https://github.com/gpampara/scalaz/blob/map/core/src/main/scala/scalaz/Map.scala

Feedback welcome - I'm really not sure about the function names (would
some symbols be better?). I've been rather swamped of late, but I hope
to get the tests and a zipper for the map done asap

[Robin P]

Remarks for \/:

- scalaz.effect.IO.catchLeft may return \/ instead of scala.Either ?
- could have apply on object \/ to convert a scala Either to \/. And maybe a .\/ on scalaz.std.EitherOps
- could have \/.mapLeft(f) = swap.map(f).swap

Robin

[Michael Pilquist]

On Sat, Aug 18, 2012 at 7:31 PM, Robin P <palota...@gmail.com> wrote:

Remarks for \/:

- scalaz.effect.IO.catchLeft may return \/ instead of scala.Either ?
- could have apply on object \/ to convert a scala Either to \/. And maybe a .\/ on scalaz.std.EitherOps

Note that those functions exist just under different names: DisjunctionFunctions#fromEither and EitherOps#disjunction.  I like aliasing fromEither/apply and disjunction/\/.

 

- could have \/.mapLeft(f) = swap.map(f).swap

I tended to do bimap(f, identity) or disj.<-:(f) instead of the double swap.  One problem with a mapLeft is that it might lead to filterLeft, flatMapLeft, etc.

Regards,

Michael

[Robin P]

Note that those functions exist just under different names: DisjunctionFunctions#fromEither and EitherOps#disjunction.  I like aliasing fromEither/apply and disjunction/\/.

True, thank you. I was using 7-M2 which still misses these. Do I see it right that in the sonatype repo there are no nightlies of scalaz-7.0.0 for scala-2.10.0-M6? Would it be hard to have?
 

 

- could have \/.mapLeft(f) = swap.map(f).swap

I tended to do bimap(f, identity) or disj.<-:(f) instead of the double swap.  One problem with a mapLeft is that it might lead to filterLeft, flatMapLeft, etc.

Understandable.

Robin