Counter proposal: Do not include whenM and ifM

[Casey McCann]

On Mon, Apr 21, 2014 at 12:55 PM, Tom Ellis
<tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote:
> I have been reading the discussion about 'whenM' and 'ifM' wondering where
> it is going to end.  Presumably we will also have 'unlessM'.  Then 'guardM'
> becomes a reasonable candidate, and indeed 'libraryFunctionM' for any
> 'libraryFunction' that happens to have a monadic return type and non-monadic
> argument.  It is as if everyone is discussing how many 'liftAn' we should
> provide when (<$>) and (<*>) already do the job generically.

What other functions, aside from guard, would this make sense for? The
only other "libraryFunctionM" candidates I can think of would require
more complex control flow and would not work with your suggestion, I
think. For example, how would you implement an unfoldM function?

For ifM &c. specifically it would work, but I find the result much
less readable. These are simple functions being reinvented to improve
readability, not to create one-liners for their own sake. I suspect
anyone using ifM now would be unlikely to replace it with what you
suggest.

As for guard, it's not necessary because it only takes one argument
and can be applied using (>>=) with no additional hassle.

> The generic alternative that I believe warrants further investigation is to
> add an operator called, for example, (<*>|) to be read as "apply and done".
> All these specific questions about whether a function should take a monadic
> argument or not are solved generically by (<$>), (<*>) and (<*>|) as
> demonstrated below.
>
> It is no more complex than just using the Applicative combinators (<$>) and
> (<*>) we know and love.
>
> It seems the discussion about 'mif' vs 'ifM' can be completely finessed.
> Those functions are no more convenient than (<*>|) syntax.  There may be an
> even better syntax than the one I propose here but I think it's actually
> pretty good as it is.

Unrelated to the ifM &c. matter, however, I actually find this
function useful and would be happy to see it included.

For what it's worth, my preferred name for it is (=<*), intended as a
portmanteau of (=<<) and (<*>). (<*>|) seems a bit awkward.

- C.