On Fri, Apr 9, 2010 at 10:20 AM, Neil Brown
Ivan Lazar Miljenovic wrote:
As of 6.12.1, the new -fwarn-unused-do-bind warning is activated with -Wall. This is based off a bug report by Neil Mitchell: http://hackage.haskell.org/trac/ghc/ticket/3263 .
However, does it make sense for this to be turned on with -Wall? For starters, why should this warning apply only to do blocks and not to explicit usage of >>, etc.? That is, the following code (as specified in the above bug report) generates an error:
do doesFileExist "foo" return 1
yet this doesn't:
doesFileExist "foo" >> return 1
The comments in that bug report actually mention "My patch does not warn on uses of >>, only in do-notation, where the situation is more clear cut". I take >> to be an explicit sign that the user wants to ignore the result of the first action, whereas in do-notation it may be an accident. So I think it was the right decision.
Relevant link: http://neilmitchell.blogspot.com/2008/12/mapm-mapm-and-monadic-statements.ht...
2. Use some function of type "(Monad m) => m a -> m ()" instead of doing "_ <-".
3. Duplicate the parser combinators in question so that I have one version that returns a value and another that does the main parser and then returns (); then use this second combinator in do blocks where I don't care about the returned value.
4. Put "-fno-warn-unused-do-bind" in the .cabal file.
The first two options don't appeal to me as being excessive usage of boilerplate; the third involves too much code duplication. However, I am loath to just go and disable a warning globally.
I'd be tempted by number two, but I it's more typing to write "ignore $" than "_ <-", so maybe 1 is the best option after all. I've frequently encountered the annoyance of monadic return values -- but to satisfy type signatures rather than avoid this warning. For example, I have a CHP parallel operator: (<||>) :: CHP a -> CHP b -> CHP (a,b) and a function writeChannel :: Chanout a -> a -> CHP (). But if you try to write a function like:
It's actually going to be named 'void': http://hackage.haskell.org/trac/ghc/ticket/3292 I don't think it's made it into a stable release yet. -- gwern