-
Notifications
You must be signed in to change notification settings - Fork 5
Description
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).