You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
The text was updated successfully, but these errors were encountered:
Looking through the source, we have
AccValidation
which is has noMonad
but does accumulate errors, and we haveValidation
which is aMonad
but doesn't accumulate errors. Is there a reason thatAccValidation
doesn't have aMonad
instance? For example, I've used this in my own code: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 anApplicative
which isn't aMonad
, but the above implementation seems to contradict that assertion.The
Semigroup
constraint is there to appease the existing instance of theApplicative
superclass (now thatMonad
is a subclass ofApplicative
). 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).The text was updated successfully, but these errors were encountered: