tonymorris / validation

Validation

Several data-types like Either but with differing properties and type-class instances.

Library support is provided for those different representations, include lens-related functions for converting between each and abstracting over their similarities.

Download from hackage.

• Validation

  The Validation data type is isomorphic to Either, but has an instance of Applicative that accumulates on the error side. That is to say, if two (or more) errors are encountered, they are appended using a Semigroup operation.

  As a consequence of this Applicative instance, there is no corresponding Bind or Monad instance. Validation is an example of, "An applicative functor that is not a monad."

validation's Issues

Accumulating `Monad` instance?

Looking through the source, we have AccValidation which is has no Monad but does accumulate errors, and we have Validation which is a Monad but doesn't accumulate errors. Is there a reason that AccValidation doesn't have a Monad instance? For example, I've used this in my own code:

instance (Semigroup e) => Monad (AccValidation e) where
    return = pure
    (AccSuccess x) >>= f = f x
    (AccFailure e) >>= f = AccFailure e

This seems to obey the monad laws. Is there some reason to avoid it? The haddocks on hackage specifically say that AccValidation is an example of an Applicative which isn't a Monad, but the above implementation seems to contradict that assertion.

The Semigroup constraint is there to appease the existing instance of the Applicative superclass (now that Monad is a subclass of Applicative). My intuition is that two operations combined "applicatively" are independent, and hence we're able to report errors from both (given a suitable way to combine such errors, i.e. Semigroup), whilst two operations combined "monadically" are 'chained', such that the second operation is applied to successful results from the first, and hence if the first operation fails we have no way to know what errors the second operation "might have encountered" (since we have no input to run it on).

Unnecessary specialisation

<edwardk> isoAccValidationEither ::
<edwardk>   Iso' (AccValidation e a) (Either e a)
<edwardk>  should probably be a full Iso
<edwardk> isoAccValidationEither :: Iso (AccValidation e a) (AccValidation f b) (Either e a) (Either f b)
<dibblego> yes good point
<edwardk> code doesn't change. it just gets more powerful
<edwardk> same with the rest

Unnecessary Language Extension

NoImplicitPrelude adds nothing in this case, because Prelude is later imported anyway. An explicit Prelude import always overrides the implicit Prelude import (except for instances, which are imported by the explicit import anyway).

assoc-1.1 not allowed

It would be nice if this newer dependency was allowed, since then Stackage could upgrade to use this version:

• commercialhaskell/stackage/issues/6915