Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a lazier version #53

Open
treeowl opened this issue Jun 11, 2021 · 4 comments
Open

Add a lazier version #53

treeowl opened this issue Jun 11, 2021 · 4 comments

Comments

@treeowl
Copy link
Contributor

treeowl commented Jun 11, 2021

In case of failure, one may be interested in only the first few errors, but Validation requires that everything be checked regardless. A version with a Monoid rather than Semigroup constraint could allow this in the list monoid with something like

liftA2 _ (Failure e1) m = Failure $ e1 <> case m of
  Failure es -> es
  Success _ -> mempty
@tonymorris
Copy link
Contributor

Good point!

@treeowl
Copy link
Contributor Author

treeowl commented Nov 9, 2021

In think in principle, neither Semigroup nor Monoid is the right underlying class when taking laziness into account.

class Accumulate a where
  accum :: a -> Maybe a -> a

newtype Semi a = Semi { unSemi :: a }
newtype Mon a = Mon { unMon :: a }

instance Semigroup a => Accumulate (Semi a) where
  accum a (Just b) = a <> b
  accum a Nothing = a

instance Monoid a => Accumulate (Mon a) where
  accum a mb = a <> maybe mempty id mb

@tonymorris
Copy link
Contributor

Has this class been published?

@treeowl
Copy link
Contributor Author

treeowl commented Nov 11, 2021

Not that I know of. It's an oddball. I think it would likely be best to just add the lazier, Monoid-based version of Validation as Data.Validation.Lazy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants