[Haskell] Types of when and unless in Control.Monad

[Henning Thielemann]

On Tue, 5 Jun 2012, Andreas Abel wrote:

>> I would prefer these strict types, too.
>
> Ok, well, then you probably would not want to use mapM_ and the like, but 
> instead
>
>  mapM (void . f) l

This would result in 'm [()]' not in 'm ()'. I could e.g. get information 
from the number elements in the [()] list, but () tells me nothing. Thus 
they are really different.


>> Alternatively I have wondered in the past whether it might be a good
>> idea to generalize them to:
>> 
>>> mapM_ :: Monoid b => (a -> m b) -> [a] -> m b
>>> forM_ :: Monoid b => [a] -> (a -> m b) -> m b
>>> sequence_ :: Monoid b => [m b] -> m b
>>> forever :: Monoid b => m b -> m b
>> 
>> This would still propagate monadic result type () if the final monadic
>> action has result type ().
>> 
>> http://www.haskell.org/pipermail/haskell-cafe/2009-January/054243.html
>
> But that would not be backwards compatible.

Not completely. You may need additional type annotations.


>> Since the addition of 'void' the noise has become acceptable for me.
>> 
>> I would follow a kind of "separation of concerns". Ignoring results is
>> one step and performing forM_, when etc. is the second step.
>
> Ok.  But I am really surprised that an operation should not get the maximally 
> sensible type.

There are other functions, like 'asTypeOf' that have intentionally not the 
most general type. :-)

My concern is safety and safety means to intentionally forbid things. 
That's why I prefer Haskell to C or MatLab. E.g. C by default ignores 
results from functions if they are not used. But this way, people may 
write (a==b;) instead of (a=b;) without noticing the mistake.


> The application is that I have a function that provides a resource that may 
> be present or not.  If it is not present, an exception is thrown (that is the 
> monadic effect).  If I am just interested in checking the presence of the 
> resource, I can call this function in a do-block.  But I am not allowed to 
> call it in a 'when', without 'void'ing it.  That is counterintuitive.

How do you free the resource if you ignore the returned handle?

If checking for an exception this way is a common pattern in your code, 
how about writing a function that catches the exception and run some code, 
if there is no exception? It might have a signature like

whenAvailable :: IO resource -> IO () -> IO ()

and might be used like this

whenAvailable getResource $ do
    thingsToDoWhenResourceIsAvailable

> To reconcile the 'strict' vs. 'liberal' programmers, it seems that library 
> functions need to have different types depending on whether
>
>  -fwarn-unused-do-bind
>
> is set or not...

Something like a type system that does not only support 'correct' and 
'wrong', but also 'suspect', would solve the problem. :-)