Counter proposal: Do not include whenM and ifM

[Tom Ellis]

On Mon, Apr 21, 2014 at 01:15:30PM -0400, Casey McCann wrote:
> 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?

Well, they're not necessarily functions in base, but many library authors
are going to have to ask themselves similar questions about functions like
this.  Let's deal with them all in one go if we can.

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

Maybe, but I propose we give them that opportunity before adding 'ifM' and
company.

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

You're right.  'guard' was a red herring.  My mistake.

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

I have no preference regarding the name.  I chose it arbitrarily.

Tom