Pre-Proposal: Add Validation somewhere easily accessible

Joseph Abrahamson me at
Sun Sep 21 17:05:42 UTC 2014

The “purely applicative Either” is Either with a new Applicative interface which can no longer take a corresponding Monad interface. I have personally reinvented it over and over although it is perhaps commonly known as Validation:

    data Validation e a = Invalid e | Valid a deriving ( Show, Functor, … )

    instance Monoid e => Applicative (Validation e) where
      pure = Valid
      Invalid e1 <*> Invalid e2 = Invalid (e1 <> e2)
      Invalid e1 <*> _          = Invalid e1
                 <*> Invalid e2 = Invalid e2
      Valid   f  <*> Valid   a  = Valid (f a)

    -- No corresponding Monad

It could be perhaps better implemented as a newtype wrapper over Either to facilitate rapid conversion to the more common type.

Validation appears in its own package developed by Tony Morris and Nick Partridge. It also exists in Jonathan Sterling’s Vinyl package under the name Data.Vinyl.Idiom.Validation.Result. Gabriel Gonzalez has also told me that he’d be happy to add it to his `errors` package if a PR was made.

The common use for Validation is to traverse over a structure and accumulate errors throughout it. In other words, failures should not halt the process and we can think of each operation as occurring in parallel.

Not only is Validation a good example of an “Applicative without a Monad” its also a very useful practical type.

I would like to build a proposal to include Validation in some form in a common package. Despite the misalignment with the name, `transformers` seems like a plausible target, though I fear changes to that package are rarely worth the pain. Suggestions on implementation and target package are welcome. Pending informative feedback, I will try to write a true proposal within 2 weeks.

Thanks everyone,


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list