Skip to content

Accumulating Monad instance? #11

@Warbo

Description

@Warbo

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).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions