#3263: Warnings for monadic values not used
-----------------------------+----------------------------------------------
Reporter:  NeilMitchell      |          Owner:                  
    Type:  feature request   |         Status:  new             
Priority:  normal            |      Component:  Compiler        
 Version:  6.10.2            |       Severity:  normal          
Keywords:                    |       Testcase:                  
      Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
-----------------------------+----------------------------------------------
 I would like two warnings. The first {{{-fwarn-unused-monad-bind}}}:

 {{{
 do doesFileExist "foo" ; return 1
 }}}

 {{{doesFileExist}}} returns a value of {{{IO Bool}}}, not {{{IO ()}}}, and
 does not bind it's result. This warning should be applied to both {{{do}}}
 notation and {{{>>}}} and should fire on all values which aren't {{{m
 ()}}}.

 The second {{{-fwarn-wrong-bind}}}:

 {{{
 do return (doesFileExist "foo") ; return 1
 }}}

 {{{doesFileExist}}} returns a value of type {{{IO (IO a)}}}, which is not
 bound. This warning should fire on all {{{m (m a)}}} values and also in
 {{{>>}}}.

 The names of the flags are intended to be placeholders for a sensibly
 chosen name. I would make {{{-fwarn-wrong-bind}}} on as a default warning,
 and both turned on under {{{-Wall}}}. I'm not sure anyone has ever written
 the second construction without it being a serious error. In the case of
 {{{IO}}} it's really easy to miss that some side effects are no longer
 happening after a refactoring. I've just made this very mistake in fairly
 public way.

 It seems that problems such as {{{mapM}}} space leaks are common, and that
 it is not widely known that such constructions without a named binding are
 always wrong. I've had to explain the problem to fairly experienced
 Haskell programmers.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3263>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Reply via email to