#3263: Warnings for monadic values not used
------------------------------+---------------------------------------------
 Reporter:  NeilMitchell      |          Owner:                  
     Type:  feature request   |         Status:  new             
 Priority:  normal            |      Milestone:                  
Component:  Compiler          |        Version:  6.10.2          
 Severity:  normal            |     Resolution:                  
 Keywords:                    |       Testcase:                  
       Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
------------------------------+---------------------------------------------
Comment (by isaacdupree):

 Quite an interesting idea!

 -fwarn-unused-monad-bind: as well as (), it should exclude returns that
 are polymorphic in any value (this idiom is sometimes used for functions
 that do not return, such as `exitWith :: ExitCode -> IO a` and possibly
 [parts of?] `callCC :: MonadCont m => ((a -> m b) -> m a) -> m a`)

 -fwarn-wrong-bind: good idea... and you'd get around the warning, should
 it prove necessary to, by explicitly binding to `_` (either `do _ <- ...`
 or `... >>= \_ ->`)?

 If you want to avoid `mapM` space leaks in real code among unsuspecting
 programmers, we'll need a well-designed warning-message that will convince
 them not to just write
 {{{
 --avoid silly warning: we *don't* use the result
 _ <- mapM ...
 }}}
 Possibly some pragma action could help GHC give more precise suggestions
 (like "use mapM_")

 I guess the warnings would hardcode Monad, and probably hardcode () as
 well, or would it be better (easier? harder?) to apply to any zero-
 information data (aka `data Zero` and `data One = One` and perhaps some
 newtype and/or GADT magic)?

 -Isaac Dupree

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3263#comment:1>
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