Re: [Haskell-cafe] What is the consensus about -fwarn-unused-do-bind ?
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 ivan.miljeno...@gmail.com 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is the consensus about -fwarn-unused-do-bind ?
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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is the consensus about -fwarn-unused-do-bind ?
Roel van Dijk vandijk.r...@gmail.com 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 ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is the consensus about -fwarn-unused-do-bind ?
On Tue, Apr 13, 2010 at 9:59 PM, Max Cantor mxcan...@gmail.com 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is the consensus about -fwarn-unused-do-bind ?
On Wed, 14 Apr 2010 09:15:04 -0500, Antoine Latter aslat...@gmail.com wrote: On Tue, Apr 13, 2010 at 9:59 PM, Max Cantor mxcan...@gmail.com 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is the consensus about -fwarn-unused-do-bind ?
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 ivan.miljeno...@gmail.com 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is the consensus about -fwarn-unused-do-bind ?
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 b...@serpentine.com 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 ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is the consensus about -fwarn-unused-do-bind ?
On 10 April 2010 00:20, Neil Brown nc...@kent.ac.uk 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 ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is the consensus about -fwarn-unused-do-bind ?
On 10 April 2010 02:07, Bryan O'Sullivan b...@serpentine.com 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 ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] What is the consensus about -fwarn-unused-do-bind ?
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 ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is the consensus about -fwarn-unused-do-bind ?
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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is the consensus about -fwarn-unused-do-bind ?
(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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is the consensus about -fwarn-unused-do-bind ?
On Fri, Apr 9, 2010 at 10:20 AM, Neil Brown nc...@kent.ac.uk 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is the consensus about -fwarn-unused-do-bind ?
On Fri, Apr 9, 2010 at 6:44 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com 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 ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is the consensus about -fwarn-unused-do-bind ?
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 ivan.miljeno...@gmail.com 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
