Re: Counter proposal: Do not include whenM and ifM

On Mon, Apr 21, 2014 at 01:15:30PM -0400, Casey McCann wrote:

On Mon, Apr 21, 2014 at 12:55 PM, Tom Ellis 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