What is the consensus about -fwarn-unused-do-bind ?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

What is the consensus about -fwarn-unused-do-bind ?

Ivan Lazar Miljenovic

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

If monadic code is going to return an error, then shouldn't _all_
monadic code do so, and not just those in do blocks?

Secondly, a fair number of packages seem to be disabling this globally;
the packages I know of (from mentions on mailing lists and grepping on
/srv/code/*/*.cabal on code.haskell.org) that have the
-fno-warn-unused-do-bind option being passed to GHC in their .cabal file
include:

* HsOpenCL
* leksah-server
* xmonad (including xmonad-contrib)
* xmobar
* pandoc

My reason for bringing this up is that I'm soon about to release a new
version of my graphviz library, and am debating what to do.  Note that
most of these errors are being caused by usage of a monadic-style of
parsing (before anyone tells me I should be using an Applicative style
instead, polyparse doesn't support Applicative, so I can't) and as such
the "return value" is being evaluated anyway.  The way I see it, I have
4 options:

  1. Do as the error suggests and preface usage of these parser
     combinators with "_ <-".

  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.

What does the Haskell community think?  Is -fwarn-unused-do-bind a
worthwhile warning (and code should be updated so as not to cause it to
find anything to warn about)?  Or is it more of a hindrance to be
disabled?

--
Ivan Lazar Miljenovic
[hidden email]
IvanMiljenovic.wordpress.com
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What is the consensus about -fwarn-unused-do-bind ?

Neil Brown-7
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.

When I first compiled my CHP library with it, I was surprised to find
that I had very few instances: 6 warnings in ~3000 lines of
heavily-monadic code.  And one or two of those I probably shouldn't be
ignoring the return.

> The way I see it, I have 4 options:
>
>   1. Do as the error suggests and preface usage of these parser
>      combinators with "_ <-".
>
>   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:

writeBoth :: a -> (Chanout a, Chanout a) -> CHP ()
writeBoth x (outA, outB) = writeChannel outA x <||> writeChannel outB x

You get a type error (expected: CHP (), but got: CHP ((), ()) -- both
return types contain no information anyway!).  You either have to append
">> return ()" (or similarly use do-notation), or do as I did and make
another form of the operator that discards the output (and there I can't
use the add-another-underscore convention!).

It's annoying that you end up with lots of operations in libraries
duplicated with an underscore variant, or different operators.  
Sometimes it can make an important semantic difference (e.g. mapM
requires Traversable but mapM_ only requires Foldable), but often it's
just a matter of "no, I don't care about the return value from this"
(e.g. forkIO).  I sometimes wonder if there could be some syntactic
sugar that might help, but it does feel like overkill just for this purpose.

Thanks,

Neil.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What is the consensus about -fwarn-unused-do-bind ?

Malcolm Wallace
In reply to this post by Ivan Lazar Miljenovic
> (before anyone tells me I should be using an Applicative style
> instead, polyparse doesn't support Applicative, so I can't)

Well, polyparse may not support the Applicative class defined in  
Control.Applicative, but it _does_ have an applicative interface using  
other names for the same operators (namely, pure == return, (<*>) ==  
apply, (<*) == discard, (<|>) = onFail).

> 2. Use some function of type "(Monad m) => m a -> m ()" instead of  
> doing
>     "_ <-".

This function was discussed on the libraries list in the last year or  
so.  I think the consensus name for it was "void".  Of your 4  
alternatives, I quite like this one.

Regards,
     Malcolm

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What is the consensus about -fwarn-unused-do-bind ?

Gwern Branwen
In reply to this post by Neil Brown-7
On Fri, Apr 9, 2010 at 10:20 AM, Neil Brown <[hidden email]> wrote:

> 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.html

>>  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
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What is the consensus about -fwarn-unused-do-bind ?

Bryan O'Sullivan
In reply to this post by Ivan Lazar Miljenovic
On Fri, Apr 9, 2010 at 6:44 AM, Ivan Lazar Miljenovic <[hidden email]> 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?

Personally, I find it to be tremendously noisy and unhelpful, and I always edit my .cabal files to turn it off. I think of it as a usability regression.

 
 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

If monadic code is going to return an error, then shouldn't _all_
monadic code do so, and not just those in do blocks?

Secondly, a fair number of packages seem to be disabling this globally;
the packages I know of (from mentions on mailing lists and grepping on
/srv/code/*/*.cabal on code.haskell.org) that have the
-fno-warn-unused-do-bind option being passed to GHC in their .cabal file
include:

* HsOpenCL
* leksah-server
* xmonad (including xmonad-contrib)
* xmobar
* pandoc

My reason for bringing this up is that I'm soon about to release a new
version of my graphviz library, and am debating what to do.  Note that
most of these errors are being caused by usage of a monadic-style of
parsing (before anyone tells me I should be using an Applicative style
instead, polyparse doesn't support Applicative, so I can't) and as such
the "return value" is being evaluated anyway.  The way I see it, I have
4 options:

 1. Do as the error suggests and preface usage of these parser
    combinators with "_ <-".

 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.

What does the Haskell community think?  Is -fwarn-unused-do-bind a
worthwhile warning (and code should be updated so as not to cause it to
find anything to warn about)?  Or is it more of a hindrance to be
disabled?

--
Ivan Lazar Miljenovic
[hidden email]
IvanMiljenovic.wordpress.com
_______________________________________________


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What is the consensus about -fwarn-unused-do-bind ?

Iustin Pop
On Fri, Apr 09, 2010 at 09:07:29AM -0700, Bryan O'Sullivan wrote:

> On Fri, Apr 9, 2010 at 6:44 AM, Ivan Lazar Miljenovic <
> [hidden email]> 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?
>
>
> Personally, I find it to be tremendously noisy and unhelpful, and I always
> edit my .cabal files to turn it off. I think of it as a usability
> regression.

Well, I would say it could be helpful, but given that even
Text.Printf.printf triggers this error in harmless statements it is
indeed a regression.

iustin
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What is the consensus about -fwarn-unused-do-bind ?

Ivan Lazar Miljenovic
In reply to this post by Neil Brown-7
On 10 April 2010 00:20, Neil Brown <[hidden email]> wrote:
> 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.

Ahhh, I missed that bit.

--
Ivan Lazar Miljenovic
[hidden email]
IvanMiljenovic.wordpress.com
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What is the consensus about -fwarn-unused-do-bind ?

Ivan Lazar Miljenovic
In reply to this post by Bryan O'Sullivan
On 10 April 2010 02:07, Bryan O'Sullivan <[hidden email]> wrote:
> Personally, I find it to be tremendously noisy and unhelpful, and I always
> edit my .cabal files to turn it off. I think of it as a usability
> regression.

Yeah, I'm very tempted to do this as well.  This warning might make
sense for IO, but I think it's of less use for other monads.

--
Ivan Lazar Miljenovic
[hidden email]
IvanMiljenovic.wordpress.com
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What is the consensus about -fwarn-unused-do-bind ?

Max Cantor
I'm in the camp of adding -fno-warn-unused-do-bind to my cabal files.  I hate sacrificing the purity of -Wall but I have so many forkIOs in my code that I think it was the best option.

Max


On Apr 10, 2010, at 3:08 PM, Ivan Miljenovic wrote:

> On 10 April 2010 02:07, Bryan O'Sullivan <[hidden email]> wrote:
>> Personally, I find it to be tremendously noisy and unhelpful, and I always
>> edit my .cabal files to turn it off. I think of it as a usability
>> regression.
>
> Yeah, I'm very tempted to do this as well.  This warning might make
> sense for IO, but I think it's of less use for other monads.
>
> --
> Ivan Lazar Miljenovic
> [hidden email]
> IvanMiljenovic.wordpress.com
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What is the consensus about -fwarn-unused-do-bind ?

Roel van Dijk-3
Can anyone provide an example of an error that is prevented by this
warning? When exactly is it dangerous to ignore a monadic function's
return value?
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What is the consensus about -fwarn-unused-do-bind ?

Ivan Lazar Miljenovic
Roel van Dijk <[hidden email]> writes:

> Can anyone provide an example of an error that is prevented by this
> warning? When exactly is it dangerous to ignore a monadic function's
> return value?

See Neil's original rationale in the bug report:
http://hackage.haskell.org/trac/ghc/ticket/3263

Short version: using something like mapM but disregarding the result
(rather than using mapM_) can sometimes lead to space leaks.

--
Ivan Lazar Miljenovic
[hidden email]
IvanMiljenovic.wordpress.com
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What is the consensus about -fwarn-unused-do-bind ?

Antoine Latter-2
In reply to this post by Max Cantor
On Tue, Apr 13, 2010 at 9:59 PM, Max Cantor <[hidden email]> wrote:
> I'm in the camp of adding -fno-warn-unused-do-bind to my cabal files.  I hate sacrificing the purity of -Wall but I have so many forkIOs in my code that I think it was the best option.
>
> Max
>

I think a nice compromise position would be the ability to annotate a
function as "never trigger the unused do bind warning for me". That
way I could catch these errors when I care, but also continue to
ignore the return value of forkIO. I guess this doesn't help the
space-leak argument for the warning, however.

Antoine
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What is the consensus about -fwarn-unused-do-bind ?

Nicolas Pouillard-2
On Wed, 14 Apr 2010 09:15:04 -0500, Antoine Latter <[hidden email]> wrote:

> On Tue, Apr 13, 2010 at 9:59 PM, Max Cantor <[hidden email]> wrote:
> > I'm in the camp of adding -fno-warn-unused-do-bind to my cabal files.  I hate sacrificing the purity of -Wall but I have so many forkIOs in my code that I think it was the best option.
> >
> > Max
> >
>
> I think a nice compromise position would be the ability to annotate a
> function as "never trigger the unused do bind warning for me". That
> way I could catch these errors when I care, but also continue to
> ignore the return value of forkIO. I guess this doesn't help the
> space-leak argument for the warning, however.

What about defining forkIO_ as forkIO >> return (), this way there is no
ugly _ <- ... nor forgotten results?

--
Nicolas Pouillard
http://nicolaspouillard.fr
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What is the consensus about -fwarn-unused-do-bind ?

John Meacham
In reply to this post by Bryan O'Sullivan
On Fri, Apr 09, 2010 at 09:07:29AM -0700, Bryan O'Sullivan wrote:

> On Fri, Apr 9, 2010 at 6:44 AM, Ivan Lazar Miljenovic <
> [hidden email]> 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?
>
>
> Personally, I find it to be tremendously noisy and unhelpful, and I always
> edit my .cabal files to turn it off. I think of it as a usability
> regression.

I strongly agree.

I do not even think it is bad style to ignore the result of a monad,
depending on the particular monad used, it could be extremely common. If
anything there should be a pragma one can attach to ceratin functions to
warn if the result is unused, like 'mapM'. This would be similar to what
gcc does, where you can specify an attribute saying a functions result
should be used or the compiler should complain.

        John


--
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What is the consensus about -fwarn-unused-do-bind ?

Henning Thielemann-4
John Meacham schrieb:

> On Fri, Apr 09, 2010 at 09:07:29AM -0700, Bryan O'Sullivan wrote:
>> On Fri, Apr 9, 2010 at 6:44 AM, Ivan Lazar Miljenovic <
>> [hidden email]> 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?
>>
>> Personally, I find it to be tremendously noisy and unhelpful, and I always
>> edit my .cabal files to turn it off. I think of it as a usability
>> regression.
>
> I strongly agree.
>
> I do not even think it is bad style to ignore the result of a monad,
> depending on the particular monad used, it could be extremely common. If
> anything there should be a pragma one can attach to ceratin functions to
> warn if the result is unused, like 'mapM'. This would be similar to what
> gcc does, where you can specify an attribute saying a functions result
> should be used or the compiler should complain.

The question is: Would people design libraries in a different way, if it
is encouraged to respect monadic results?
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe