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

5 Jun 2012

      On 06/04/2012 08:47 PM, Christian Höner zu Siederdissen wrote:
...
Hi Andreas,
I think you missed our point. Say:
gearDown :: IO Bool
landPlane :: IO ()
do
   g<- gearDown
   if g
   then landPlane
   else error "we're all gonna die, bail out"
But now, I am really lazy (in a bad way)
do
   when gearDown
   landPlane
You probably meant to write

   do gearDown
      landPlane

(Since 'when' expects a pure Bool, the code you wrote does not 
type-check.)  Well, you can ignore results in a 'do', but this has 
nothing to do with 'when'.  There is a ghc flag

   -fwarn-unused-do-bind

that prevents you from ignoring results silently, in this case you would 
have to write

   do _ <- gearDown
      landPlane

to make it obvious that you ignore a result of a monadic computation. 
Maybe you prefer this style, but I would like the freedom to silently 
ignore unneeded results.
...
I can not now accidentally land my plane if my gear ist stuck in "up"
(returned false). If "when" suppresses the return value, the compiler
does not warn you if you use "when" together with a function that
returns something important.
It seems you have confused condition- and then-part of 'when'.
...
My point is /not/ that I want the result of "when", but that I want to
know that I am currently suppressing the result of the inner action,
which could be disastrous.
And simply adding "when_" is the safest (one of the safer?) way of
dealing with your wish.
The reason to have a mapM_ additionally to mapM is that in some cases, 
e.g. as last statement of a do block of type m (), mapM does not type check.

However, generalizing the type of 'when' does not break any programs, 
and then a when_ is superfluous.

More in an answer to Henning...

Cheers,
Andreas
...
* Andreas Abel  [04.06.2012 20:36]:
...
On 04/22/2012 01:49 PM, Ivan Lazar Miljenovic wrote:
...
On 22 April 2012 21:39, Christian Höner zu Siederdissen
   wrote:
...
* Julian Gilbey   [22.04.2012 09:22]:
...
On Sat, Apr 21, 2012 at 08:28:27PM -0500, Strake wrote:
...
On 21/04/2012, Andreas Abel   wrote:
> to avoid silly "return ()" statements like in
>
>     when cond $ do
>       monadicComputationWhoseResultIWantToDiscard
>       return ()
(when cond ∘ void) monadicComputationWhoseResultIWantToDiscard
or
when cond $ ()<$ monadicComputationWhoseResultIWantToDiscard
How is that simpler than
when cond monadicComputationWhoseResultIWantToDiscard
which it would be with the suggested new type?
Julian
Wouldn't "when_" and "unless_" or similar be better? I'd probably like
to have the compiler annoy me, since it is not clear that I want to
discard the result. If I really want to discard, I should have to make
it clear as there is probably a good reason for the inner function to
return a result in the first place?
Agreed; I'm not sure if I agree with having such functionality
(Henning makes some good points), but if people deem it desirable then
I think it would be better to have them with new names for the reasons
you state.
Mmh, this discussion has cooled down, but I just found your answers
which had been stashed away by my mail agent, and I feel I have to
reply...
Concerning the suggestion that when_ would be in sync with forM_ and
whenM_ I'd say: not really.  forM_ and whenM_ discard the result of
the monadic computation, while when and when_ do not even have such
a result.  They always just perform some monadic effect and return
nothing.
Repeating myself, 'when' can never have a result, since it is an
if-then without an else.  Thus, it is a proper command; and if you
want to have a conditional monadic computation which does return a
result, you can simply not use 'when' or 'unless', logic forces you
to use 'if' or 'ifM'.
I do not understand the worries that one could accidentially use
'when' with a monadic computation whose result one actually cares
for.  If that was the intention of the library designers, they
should have given many other function a more specific type, most
prominently
...
...
:: m () ->  m b ->  b
That would have ensured that you cannot discard the result of the
first computation by accident.  But would you want to work with
this?  My answer is no.
Other types that would be changed to implement this kind of safety
policy are:
mapM_ :: (a ->  m ()) ->  [a] ->  m ()
   forM_ :: [a] ->  (a ->  m ()) ->  m ()
   sequence_ :: [m ()] ->  m ()
   forever :: m () ->  m ()
and many more, like zipWithM_, foldM_, replicateM_.
Sorry, but I think all these function have been given their maximal
general type
==>  to be able to ignore a result of a monadic computation
==>  without further noise.
In my opinion, the types of when and unless are not general enough,
an that is, imho, just an accident of history.  Because it is the
type that inferred for the shortest definition, which is
when cond m = if cond then m else return ()
Please reevaluate my proposal to change to
when   :: Bool ->  m a ->  m ()
   unless :: Bool ->  m a ->  m ()
in the light of the above arguments.
Cheers,
Andreas
--
Andreas Abel<><       Du bist der geliebte Mensch.
Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY
andreas.abel@ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/
-- 
Andreas Abel  <><      Du bist der geliebte Mensch.

Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY

andreas.abel@ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/