Proposal: add new function "check" to Control.Monad

[Sebastian Fischer]

On Aug 26, 2009, at 7:52 PM, Jon Fairbairn wrote:

> When designing a library, one should choose
> the primitives so that future definitions are simple, both in
> the complexity of the terms needed to define them and in the
> thought needed to define them, rather than the simplicity of
> definition of the primitives themselves. The reason that I
> suggested check is that it seems to me that it gives both of
> those things in a way that guard doesn't

I see. Also the type of guard is indeed unusual. Historically, guard  
seems inspired by conditions in list comprehensions but I would  
appreciate a sensible refactoring.

When designing MonadPlus combinators from scratch I would probably  
implement

   filter :: MonadPlus m => (a -> Bool) -> m a -> m a

as a generalisation of the list function with the same name. After  
Davids remarks I'm not sure whether I would need

   check f = filter f . return

I agree to you reasoning to prefer check over guard but go one step  
further and prefer filter over check.

I would vote for adding a generalized filter to Control.Monad. Using  
the name of the Prelude function on lists is justified because it is a  
generalisation just like many functions in Data.Foldable which also  
reuse Prelude names.

Cheers,
Sebastian

-- 
Underestimating the novelty of the future is a time-honored tradition.
(D.G.)