• A few words about this package
• Example data type and very small usage example
• Comparison to (some) other packages
• How to use this package (dependency in the .cabal file, add import, etc.)

It would be useful to compare validation-selective with Alexis King's monad-validate library.

commercialhaskell/stackage#5406

This package depends on selective < 0.7 and that does not compile with ghc-9.6.

I am currently getting around this in my cabal.project file using:

if impl(ghc >= 9.6)
  allow-newer:
    , validation-selective:selective

to allow the use of selective == 0.7.

Will help close commercialhaskell/stackage#6348.

Often, when using validation-selective, you write code like:

validateUser user = user <$ failureIf (someUserCheck user) SomeError

We can probably introduce one more helpful combinator to write domain checks even easier, a function like this:

guardedWith :: (a -> Bool) -> e -> a -> Validation (NonEmpty e) a
guardedWith p e a = a <$ failureIf (p a) e

And the previous code example will be rewritten like this:

validateUser = guardedWith someUserCheck SomeError

An open question is how to name this function 🙂 So any ideas are welcome!

A lot of great suggestions by @vrom911 in this PR: #6

Specifically:

• Better documentation for the Validation data type
• Rewrite example with Computer: probably a completely different example where validation makes more sense is required, like a form with user name and list of some non-empty strings or something different. And probably it's better to use newtypes.
• Add better docs to each instance with doctest examples
• Make each instance description more high-level

http://hackage.haskell.org/package/base-4.12.0.0/docs/Data-Data.html#t:Data

When using Validation, we often work with the NonEmpty list of errors, and those lists will be concatenated later. I propose to introduce two functions to help with writing more concise code. I'm not sure about names, this is the most difficult part here, so any suggestions are appreciated:

failure :: e -> Validation (NonEmpty e) a
failureIf :: Bool -> e -> Validation (NonEmpty e) ()
failureUnless :: Bool -> e -> Validation (NonEmpty e) ()  -- equal to 'failureIf (non p)'

So instead of:

validateName :: String -> Validation (NonEmpty FormValidationError) UserName
validateName name
    | null name = Failure (EmptyName :| [])
    | otherwise = Success (UserName name)

we will write

validateName :: String -> Validation (NonEmpty FormValidationError) UserName
validateName name = UserName name <$ failureIf (null name) EmptyName

or even like this (with slightly different type):

validateName :: String -> Validation (NonEmpty FormValidationError) UserName
validateName name = UserName <$> failureIf null EmptyName name

My case is this:

I want to type check a recursive expression and the type checking may depend on the type of the child expressions. I want to collect all the errors from all the children, but if one of my children has an error, there is no need to report another error for this node as well.

Basically I want the Either monad instance for the specific case, but the applicative of Validation for everything else. Or not even that. If this had the Either monad instance (which obviously won't happen), I would still have to write:

tpCheck :: Exp () -> Validation (Exp Tp)
tpCheck (BinaryExp op a b ()) = do
  (ta, tb) <- (,) <$> tpCheck a <*> tpCheck b
  BinaryExp op ta tb <$> tpCheckBinary op ta tb
  
 tpCheckBinary :: Op -> Exp Tp -> Exp Tp -> Validation Tp

which feels kind of indirect and silly, with the (,) <$> part. I wonder if there is some kind of operator that would allow me to do the whole thing more directly:

tpCheck (BinaryExp op a b ()) = do
  tpCheckBinary op <$!?> tpCheck a <*> tpCheck b
  
tpCheckBinary :: Op -> Exp Tp -> Exp Tp -> Validation (Exp Tp)

From my understanding, selective is more restrictive and wouldn't allow expressing this, since it really wants to collect errors from everything?

Maybe the answer is to just use another Validation library with a non-law abiding instance and accept the slight ugliness and the need to be careful? Or to manually convert it back and forth to Either?

Could the library be re-added to stack ?

At the moment it's listed as unmaintained commercialhaskell/stackage#6486 (comment) i guess it's meant unmaintained from that point onward

• whenSuccess
• whenFailure
• whenSuccess_
• whenFailure_
• whenSuccessM
• whenFailureM

empty <*> f = empty

See here: https://wiki.haskell.org/Typeclassopedia#Laws_6

Specifically:

• sconcat in Semigroup
• stimes in Semigroup
• mconcant in Monoid
• liftA2 in Applicative
• sequenceA in Traversable
• All Foldable methods

This will require to add deepseq to dependencies, but that's okay, it's a boot library. However, having NFData instance will help us and other people to write benchmarks including Validation. This will also require to derive Generic which is nice in general.

Hello to both of you,
thanks for your work that helps a lot to understand Haskell concepts.

Not really a bug here, but some comments based on your tutorial, that are hopefully useful.

First, isn't it error prone to do this :

validateName name = UserName name <$ failureIf (null name) EmptyName

I see a risk of validating a value and building another value. I see <$ as a smell, and would rather use <$>.

Here, my intuition would be to have a helper validate like this :

validate :: (a -> Bool) -> e -> a -> Validation (NonEmpty e) a
validate p  e x = if p x then Success x else failure e

allowing me to write

validateName' :: String -> Validation (NonEmpty FormValidationError) UserName
validateName' name = UserName <$> validate (not . null) EmptyName name

Or maybe even

validate :: (a -> Bool) -> (a -> b) -> e -> a -> Validation (NonEmpty e) b
validate p c e x = if p x then Success (c x) else failure e

then

validateName :: String -> Validation (NonEmpty FormValidationError) UserName
validateName = validate (not . null) UserName EmptyName

I think it reads quite well, and also avoids building a wrong result.
One could also imagine some variants of validate, taking id or const () instead of the constructor

What do you think ?

Another thing I would like to comment is the validateAll function.

It is defined as

validateAll
    :: forall e b a f
    .  (Foldable f, Semigroup e)
    => f (a -> Validation e b)
    -> a
    -> Validation e a

We are throwing the b values produced by the validations, and I think the result type is surprising too.

I would rather expect, hoping that the validators all returns the same value :

validateAll
    :: forall e b a f
    .  (Foldable f, Semigroup e)
    => f (a -> Validation e b)
    -> a
    -> Validation e b

But then, what would b be when the foldable is empty ?

So if we really want to provide a validateAll function, I would rather do :

validateAll :: Semigroup e => NonEmpty (a -> Validation e b) -> a -> Validation e b
validateAll fs a = head <$> traverse ($ a) fs

which is only keeping the first produced value, so it might not be so nice.
Maybe validateAll is not needed, and *> would be clearer.

Here again, I would be happy to know your point of you.

We can add more interface functions, similar to Either:

• http://hackage.haskell.org/package/base-4.12.0.0/docs/Data-Either.html

Specifically:

• isFailure
• isSuccess
• validation eliminator (similar to either function)
• failures
• successes
• partitionValidations
• fromFailure
• fromSuccess

Any other ideas?

As demonstrated by #69 validation-selective builds with base < 4.19, so can you please make that revision on Hackage?

Would the maintainers here be open to adding this library to stackage?

It should be on each CI (Travis, AppVeyor and GitHub actions), so shouldn't be a problem to support it.