Re: [Haskell-cafe] coding standard question
2009/6/22 Malcolm Wallace malcolm.wall...@cs.york.ac.uk: Erik de Castro Lopo mle...@mega-nerd.com wrote: Vasili I. Galchin wrote: where/let functions use the same name for function parameters as the outer function and hence there is a shadow warning from the compiler. In Haskell there is an easy way around this. Variables can be name a, a', a'' and so on. ... ... its a good idea to fix these warnings. I would _strongly_ advise not to do that. By trying to silence the spurious warning about shadowing, there is enormous potential to introduce new bugs that were not there before. Example: f a b = g (a+b) (b-a) where g a c = a*c ghc warns that g's parameter a shadows the parameter to f. So we introduce a primed identifier to eliminate the warning: f a b = g (a+b) (b-a) where g a' c = a*c Now, no warnings! But, oops, this function does not do the same thing. We forgot to add a prime to all occurrences of a on the right-hand-side. Particularly in larger examples, it can be remarkably easy to miss an occurrence of the variable whose name you are refactoring. The key point is that in this situation, unlike most refactorings, the compiler _cannot_ help you find the mistake with useful error messages or warnings. What about an editor (or emacs mode or…) that support variable renaming? Maybe there is already one? Loup ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] coding standard question
Hello Daniel and all, Your suggestion #1 : Can't import Database.HDBC.MySQL.Connection : da...@pcdavid2:~/projets/haskell/caimonitor$ ghci -Wall Bdd.hs GHCi, version 6.10.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Bdd.hs:15:7: Could not find module `Database.HDBC.MySQL.Connection': it is a hidden module in the package `HDBC-mysql-0.6' Use -v to see a list of the files searched for. Failed, modules loaded: none. Prelude Leaving GHCi. Your suggestion #2 : Unfortunately, the type isn't exported, as it seems : The doc says : *This module provides a MySQL driver for the HDBC database interface. To use it, invoke the 'connectMySQL' method to create an @Database.HDBC.IConnection@ that you can use to interact with a MySQL database. Use the 'defaultMySQLConnectInfo', overriding the default values as necessary.* so I tried : connecter :: IO IConnection connecter = connectMySQL mysqlInfo But then that didn't work too, because IConnection is a class, not a type ( which is not obvious from the documentation snippet I read) So then I tried : connecter :: IConnection conn = conn connecter = connectMySQL mysqlInfo And even though I suspect that's the correct type, it fails too : da...@pcdavid2:~/projets/haskell/caimonitor$ ghci -Wall Bdd.hs GHCi, version 6.10.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. [2 of 2] Compiling Bdd ( Bdd.hs, interpreted ) Bdd.hs:27:12: Couldn't match expected type `conn' against inferred type `HDBC-mysql-0.6:Database.HDBC.MySQL.Connection.Connection' `conn' is a rigid type variable bound by the type signature for `connecter' at Bdd.hs:26:25 Expected type: IO conn Inferred type: IO HDBC-mysql-0.6:Database.HDBC.MySQL.Connection.Connection In the expression: connectMySQL mysqlInfo In the definition of `connecter': connecter = connectMySQL mysqlInfo I looked at Connection.hsc from the library and the Connection type defined there isn't exported. For now, I've disabled that type of warnings. Thanks, David. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] coding standard question
Jochem Berndsen wrote: My default is to start developing, then adding -Wall -Werror and make it compile again. That and hlint! Martijn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] coding standard question
Am Montag 29 Juni 2009 10:47:05 schrieb david48: Hello Daniel and all, Your suggestion #1 : Can't import Database.HDBC.MySQL.Connection : da...@pcdavid2:~/projets/haskell/caimonitor$ ghci -Wall Bdd.hs GHCi, version 6.10.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Bdd.hs:15:7: Could not find module `Database.HDBC.MySQL.Connection': it is a hidden module in the package `HDBC-mysql-0.6' Use -v to see a list of the files searched for. Failed, modules loaded: none. Prelude Leaving GHCi. That wouldn't help, actually, it doesn't export the type either, as the sources revealed. Your suggestion #2 : Unfortunately, the type isn't exported, as it seems : The doc says : *This module provides a MySQL driver for the HDBC database interface. To use it, invoke the 'connectMySQL' method to create an @Database.HDBC.IConnection@ that you can use to interact with a MySQL database. Use the 'defaultMySQLConnectInfo', overriding the default values as necessary.* so I tried : connecter :: IO IConnection connecter = connectMySQL mysqlInfo But then that didn't work too, because IConnection is a class, not a type ( which is not obvious from the documentation snippet I read) So then I tried : connecter :: IConnection conn = conn connecter = connectMySQL mysqlInfo And even though I suspect that's the correct type, it fails too : No, that's too general a type, that says whatever inctsnce of IConnection you desire, I can deliver it, but connecter can deliver only one type (and there's an IO missing). Since the type is not exported, you can't use it in type signatures. You have two options: a) omit the type signature :( b) wrap it in a ConnWrapper: connecter :: IO ConnWrapper connecter = ConnWrapper `fmap` connectMySQL mysqlInfo and use it via withWConn c) maybe there's another option I didn't see I looked at Connection.hsc from the library and the Connection type defined there isn't exported. For now, I've disabled that type of warnings. Thanks, David. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] coding standard question
On Mon, Jun 29, 2009 at 3:41 PM, Daniel Fischerdaniel.is.fisc...@web.de wrote: Am Montag 29 Juni 2009 10:47:05 schrieb david48: connecter :: IConnection conn = conn connecter = connectMySQL mysqlInfo And even though I suspect that's the correct type, it fails too : No, that's too general a type, that says whatever inctsnce of IConnection you desire, I Ah, got that now. can deliver it, but connecter can deliver only one type (and there's an IO missing). Wow I don't know how I managed to leave out the IO part of the signature since it's there in my source and I thought I copy-pasted. For now I omit the type signature. Thanks ! David. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] coding standard question
On Thu, Jun 25, 2009 at 3:27 AM, wren ng thorntonw...@freegeek.org wrote:
If certain warnings truly are spurious and unavoidable, then it's best to
document this explicitly in the code by pragmas to disable the relevant
warnings. This way the spurious nature of the warning is documented (for
future maintainers, including yourself) and the distracting output of the
compiler is removed as well. Unfortunately, GHC only gives whole-file scope
for disabling warnings, but that could be fixed with enough work.
Hello all,
Forgive me if I'm a bit out of topic, but following this thread, I
decided to add -Wall -Werror for a program I'm working on.
I've spend a bit of time correcting quite a lot of warnings, most of
them being about missing type signatures. I've corrected them all, but
there remains one that I can't : ghc refuses the type signature it
suggests me.
Anyone has any idea ?
=
da...@pcdavid2:~/projets/haskell/caimonitor$ ./g
[3 of 4] Compiling Bdd ( Bdd.hs, Bdd.o )
Bdd.hs:27:0:
Warning: Definition but no type signature for `connecter'
Inferred type: connecter :: IO
HDBC-mysql-0.6:Database.HDBC.MySQL.Connection.Connection
no location info:
Failing due to -Werror.
=
Here's part of the code : without -Werror, the code compiles and works fine.
==
module Bdd where
import Database.HDBC
import Database.HDBC.MySQL
import Text.Printf
import Messages
mysqlInfo :: MySQLConnectInfo
mysqlInfo = defaultMySQLConnectInfo { mysqlHost =xxx.xxx.xxx.xxx
, mysqlUser =
, mysqlPassword =
, mysqlDatabase = xx
, mysqlPort = 0
, mysqlUnixSocket =
}
--connecter :: IO Database.HDBC.MySQL.Connection.Connection
connecter= connectMySQL mysqlInfo
...
...
...
==
Thanks,
David
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] coding standard question
Am Freitag 26 Juni 2009 11:30:32 schrieb david48:
On Thu, Jun 25, 2009 at 3:27 AM, wren ng thorntonw...@freegeek.org wrote:
If certain warnings truly are spurious and unavoidable, then it's best to
document this explicitly in the code by pragmas to disable the relevant
warnings. This way the spurious nature of the warning is documented (for
future maintainers, including yourself) and the distracting output of the
compiler is removed as well. Unfortunately, GHC only gives whole-file
scope for disabling warnings, but that could be fixed with enough work.
Hello all,
Forgive me if I'm a bit out of topic, but following this thread, I
decided to add -Wall -Werror for a program I'm working on.
I've spend a bit of time correcting quite a lot of warnings, most of
them being about missing type signatures. I've corrected them all, but
there remains one that I can't : ghc refuses the type signature it
suggests me.
Anyone has any idea ?
=
da...@pcdavid2:~/projets/haskell/caimonitor$ ./g
[3 of 4] Compiling Bdd ( Bdd.hs, Bdd.o )
Bdd.hs:27:0:
Warning: Definition but no type signature for `connecter'
Inferred type: connecter :: IO
HDBC-mysql-0.6:Database.HDBC.MySQL.Connection.Connection
no location info:
Failing due to -Werror.
=
Here's part of the code : without -Werror, the code compiles and works
fine.
==
module Bdd where
import Database.HDBC
import Database.HDBC.MySQL
import Text.Printf
import Messages
mysqlInfo :: MySQLConnectInfo
mysqlInfo = defaultMySQLConnectInfo { mysqlHost =xxx.xxx.xxx.xxx
, mysqlUser =
, mysqlPassword =
, mysqlDatabase = xx
, mysqlPort = 0
, mysqlUnixSocket =
}
--connecter :: IO Database.HDBC.MySQL.Connection.Connection
Looks like you must also
import Database.HDBC.MySQL.Connection
or, if the type Connection is exported from one of the imported modules, use it
unqualifed
or qualified with that module name.
connecter= connectMySQL mysqlInfo
...
...
...
==
Thanks,
David
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] coding standard question
On Mon, 22 Jun 2009, Neil Brown wrote: I would agree to a certain extent about the warnings. Name shadowing is not really a problem, and it's often hard to avoid shadowing names that already exist in an imported module (why shouldn't I have a variable named lines?). If you follow this advise: http://haskell.org/haskellwiki/Import_modules_properly then you have no problem with name clashes. It's also usually the case that when I write inexhaustive pattern matches, it's because I know that the function (in a where clause) cannot be called with the missing pattern. Then it is certainly better to show by types, which patterns are possible and which are not. If this is not possible, then is still better to use error for giving an explanation, why you think that this pattern cannot occur. Type defaulting and monomorphism bits may be useful to some, but I only usually fix them to get rid of the warning, not because they cause a problem. Type defaulting is a problem for the reader, since he can not easily infer, what type an expression has. (He must know the defaults.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] coding standard question
Magnus Therning wrote: Erik de Castro Lopo wrote: In Haskell there is an easy way around this. Variables can be name a, a', a'' and so on. Since these aid in clarity without forcing you to think up new variable names, I would suggest that its a good idea to fix these warnings. +1 (depending on context). If a more-helpful name than a' presents itself, I'll use that instead so as to avoid the problem of accidentally leaving off the apostrophe when typing quickly. The only times I'd typically run into name shadowing and it's not a bug(!) is when doing worker-wrapper functions. In these cases I tend to use go as the name of the worker, as per Don Stewart's tradition. Again, if a more-helpful name presents itself then I'll use that. (And if a more helpful name presents itself, that usually means the lambda can/should be floated out.) Speaking from experience it's good to fix all warnings, since otherwise there will be enough of them to cause a few terminal pages to scroll by when you compile and then there's a real danger of not noticing real errors. I'd pass '-Wall -Werror' to ghc to force myself to do this :-) +1. When there are many spurious warnings, users often ignore everything so long as the compiler appears to have exited successfully. Which in turn means that real warnings which can't manage to halt compilation will make it through unnoticed. When these bugs are platform-dependent, it makes tracking them down _very_ annoying. If certain warnings truly are spurious and unavoidable, then it's best to document this explicitly in the code by pragmas to disable the relevant warnings. This way the spurious nature of the warning is documented (for future maintainers, including yourself) and the distracting output of the compiler is removed as well. Unfortunately, GHC only gives whole-file scope for disabling warnings, but that could be fixed with enough work. Also from experience, I get a good feeling about software that compiles without warnings. It suggests the author cares and is indicative of some level of quality. +100. As a user, if I receive code that does not compile cleanly, I consider it to be extremely suspect. Whenever possible I will avoid that code and find something better maintained (writing it myself if need be). If it's research code (and it usually is for me), then the authors' bozo-bits tend to flip on because I have little patience for computer scientists without software development experience. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] coding standard question
Magnus Therning wrote: Also from experience, I get a good feeling about software that compiles without warnings. It suggests the author cares and is indicative of some level of quality. In contrast, I find almost all the GHC warnings to be useless, and therefore turn them off. I don't find they have a significant correlation with code quality. YMMV :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] coding standard question
I so don't want to be the one supporting your code... Jules Bean wrote on 22.06.2009 13:00: Magnus Therning wrote: Also from experience, I get a good feeling about software that compiles without warnings. It suggests the author cares and is indicative of some level of quality. In contrast, I find almost all the GHC warnings to be useless, and therefore turn them off. I don't find they have a significant correlation with code quality. YMMV :) ___ 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] coding standard question
Magnus Therning wrote: Speaking from experience it's good to fix all warnings, This was may experience from the C programming language. since otherwise there will be enough of them to cause a few terminal pages to scroll by when you compile and then there's a real danger of not noticing real errors. I'd pass '-Wall -Werror' to ghc to force myself to do this :-) I usually add -fwarn-tabs to -Wall -Werror. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] coding standard question
Miguel Mitrofanov wrote: I so don't want to be the one supporting your code... Well, that's lucky. Because you aren't. However, that's an easy arrow to fling. I say I don't find warnings useful so you suggest my code is unmaintainable. Is that based on any knowledge of my code, or the GHC warnings? I've been using GHC for years and my honest opinion is that the warnings very rarely flag an actual maintainability problem in the code I write, and very frequently annoying highlight something I knew I was doing, and did quite deliberately - most often inexhaustive patterns or shadowing. Maybe there are mistakes which you can make which the warnings usefully highlight, and maybe I just never make that kind of mistake. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] coding standard question
Jules Bean wrote on 22.06.2009 13:09: Miguel Mitrofanov wrote: I so don't want to be the one supporting your code... Well, that's lucky. Because you aren't. Exactly. However, that's an easy arrow to fling. I say I don't find warnings useful so you suggest my code is unmaintainable. Is that based on any knowledge of my code, or the GHC warnings? First of all, I never said that your code is unmaintainable. And, if it's not, i still don't want to maintain it, since we clearly have very different approaches to programming - which is, actually, a good thing (except that mine is obviously good and yours is obviously bad). I've been using GHC for years and my honest opinion is that the warnings very rarely flag an actual maintainability problem in the code I write, and very frequently annoying highlight something I knew I was doing, and did quite deliberately - most often inexhaustive patterns or shadowing. Maintainability is (mostly) NOT about how good are YOU in supporting your own code. Maybe there are mistakes which you can make which the warnings usefully highlight, and maybe I just never make that kind of mistake. It's a kind of mistakes that I can make maintaining your code, that's all. That doesn't imply that it's your fault (except that it certainly is). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] coding standard question
Erik de Castro Lopo mle...@mega-nerd.com wrote: Vasili I. Galchin wrote: where/let functions use the same name for function parameters as the outer function and hence there is a shadow warning from the compiler. In Haskell there is an easy way around this. Variables can be name a, a', a'' and so on. ... ... its a good idea to fix these warnings. I would _strongly_ advise not to do that. By trying to silence the spurious warning about shadowing, there is enormous potential to introduce new bugs that were not there before. Example: f a b = g (a+b) (b-a) where g a c = a*c ghc warns that g's parameter a shadows the parameter to f. So we introduce a primed identifier to eliminate the warning: f a b = g (a+b) (b-a) where g a' c = a*c Now, no warnings! But, oops, this function does not do the same thing. We forgot to add a prime to all occurrences of a on the right-hand-side. Particularly in larger examples, it can be remarkably easy to miss an occurrence of the variable whose name you are refactoring. The key point is that in this situation, unlike most refactorings, the compiler _cannot_ help you find the mistake with useful error messages or warnings. When I write code that shadows variable names, it is always deliberate. In fact, the language's lexical rules encourage shadowing, otherwise why have scopes at all? I think bug-introduction by the elimination of shadowing is much more common than bug-elimination by the same route. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] coding standard question
Jules Bean wrote: I've been using GHC for years and my honest opinion is that the warnings very rarely flag an actual maintainability problem in the code I write, and very frequently annoying highlight something I knew I was doing, and did quite deliberately - most often inexhaustive patterns or shadowing. I would agree to a certain extent about the warnings. Name shadowing is not really a problem, and it's often hard to avoid shadowing names that already exist in an imported module (why shouldn't I have a variable named lines?). It's also usually the case that when I write inexhaustive pattern matches, it's because I know that the function (in a where clause) cannot be called with the missing pattern. Type defaulting and monomorphism bits may be useful to some, but I only usually fix them to get rid of the warning, not because they cause a problem. The ones I find useful are unused imports (handy for tidying up the import list), overlapping patterns, missing fields, warnings about tabs and a few others. Of course, you can easily customise which warnings are on and which are off, so we can all have different preferences. It would be nice to be able to set some warnings to be errors though, while leaving others as warnings, or turned off (don't think GHC can do this?). Neil. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] coding standard question
On Mon, Jun 22, 2009 at 12:06 PM, Malcolm Wallace malcolm.wall...@cs.york.ac.uk wrote: Erik de Castro Lopo mle...@mega-nerd.com mle%2...@mega-nerd.com wrote: Vasili I. Galchin wrote: where/let functions use the same name for function parameters as the outer function and hence there is a shadow warning from the compiler. In Haskell there is an easy way around this. Variables can be name a, a', a'' and so on. ... ... its a good idea to fix these warnings. I would _strongly_ advise not to do that. By trying to silence the spurious warning about shadowing, there is enormous potential to introduce new bugs that were not there before. Example: f a b = g (a+b) (b-a) where g a c = a*c ghc warns that g's parameter a shadows the parameter to f. So we introduce a primed identifier to eliminate the warning: f a b = g (a+b) (b-a) where g a' c = a*c Now, no warnings! But, oops, this function does not do the same thing. We forgot to add a prime to all occurrences of a on the right-hand-side. Actually there's a warning: ghci let f a b = g (a+b) (b-a) where g a' c = a*c interactive:1:34: Warning: Defined but not used: `a'' Cheers, Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] coding standard question
Malcolm Wallace wrote: When I write code that shadows variable names, it is always deliberate. In fact, the language's lexical rules encourage shadowing, otherwise why have scopes at all? I think bug-introduction by the elimination of shadowing is much more common than bug-elimination by the same route. I would almost agree that blindly eliminating shadowing will lead to bugs, but they will be shallow bugs detected almost immediately. The bugs I am particularly interested in avoiding are the difficult bugs that seem to be intermittent, that only hit in certain rare situations and that take ages to find. I will gladly trade you a hundred of the first for one of the second :-). Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] coding standard question
Johan Tibell johan.tib...@gmail.com wrote: Example: f a b = g (a+b) (b-a) where g a c = a*c f a b = g (a+b) (b-a) where g a' c = a*c Actually there's a warning: interactive:1:34: Warning: Defined but not used: `a'' Clearly I simplified the example too far. Try this, only slightly more complex, example instead. Remember, the larger the example, the more likely you are to miss an occurrence. f a b = g (a+b) (b-a) where g a c = a*(c-a) f a b = g (a+b) (b-a) where g a' c = a'*(c-a) Perhaps I should advocate for a new warning in GHC to cover this case: -fwarn-mixed-scopes, which could flag the use of the unprimed a, due to being bound at an outer scope. Because warn-mixed-scopes is almost the opposite of warn-name-shadowing, then the only way to avoid warnings would be to manually lambda-lift all functions. :-) Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] coding standard question
Jules Bean wrote: Magnus Therning wrote: Also from experience, I get a good feeling about software that compiles without warnings. It suggests the author cares and is indicative of some level of quality. In contrast, I find almost all the GHC warnings to be useless, and therefore turn them off. I don't find they have a significant correlation with code quality. YMMV :) I strongly disagree with this. There is a huge difference between f (x:xs) = ... and f (x:xs) = ... f [] = error f: we expect a nonempty list The reason for this is that in the second case you express to somebody who reads your code (including yourself) that this omission was intentional. The same holds for other warnings (although I sometimes am annoyed by the shadowing warnings, I agree :). My default is to start developing, then adding -Wall -Werror and make it compile again. Regards, -- Jochem Berndsen | joc...@functor.nl GPG: 0xE6FABFAB ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] coding standard question
On Mon, 22 Jun 2009, Jules Bean wrote: Miguel Mitrofanov wrote: I so don't want to be the one supporting your code... Well, that's lucky. Because you aren't. I think the most frequent warning which denotes actually an error for me, is the 'unused identifier' warning, since there are often identifiers that I planned to use but forgot to use. The shadowing problem is less often a problem for me. When I refer to the wrong identifier this usually spotted by the type system, but the type system cannot find out the reason for the problem, namely two identifiers with the same name in the same scope. Sometimes I wish warnings would be emitted before (type) errors. For reading the code however it is a clear advantage to have separate names for separate things. The prime is not enough for me. Even more in a GHC error message, I often think identifier `bar'' refers to bar not bar'. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] coding standard question
On Mon, 22 Jun 2009, Malcolm Wallace wrote: Example: f a b = g (a+b) (b-a) where g a c = a*c ghc warns that g's parameter a shadows the parameter to f. So we introduce a primed identifier to eliminate the warning: f a b = g (a+b) (b-a) where g a' c = a*c Now, no warnings! But, oops, this function does not do the same thing. We forgot to add a prime to all occurrences of a on the right-hand-side. Actually there will be the warning, that a' is unused. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] coding standard question
Vasili I. Galchin wrote: I am working with some existing code. where/let functions use the same name for function parameters as the outer function and hence there is a shadow warning from the compiler. To me it doesn't see totally unreasonable to code like this the downside is the nasty ghc warnings. Is there a coding consensus on this issue? I'm relatively new to Haskell, but I know that in imperative languages like C, a small percentage of shadow warnings are often real bugs and hence always worth fixing if possible (sometimes the problem is in system header files and hence can't be fixed). In Haskell there is an easy way around this. Variables can be name a, a', a'' and so on. Since these aid in clarity without forcing you to think up new variable names, I would suggest that its a good idea to fix these warnings. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] coding standard question
2009/6/22 Vasili I. Galchin vigalc...@gmail.com: Hello, I am working with some existing code. where/let functions use the same name for function parameters as the outer function and hence there is a shadow warning from the compiler. To me it doesn't see totally unreasonable to code like this the downside is the nasty ghc warnings. Is there a coding consensus on this issue? Vasili I say you should change it. Any maintainer of code with shadowed variables could easily be confused, no matter what the language is. -- Deniz Dogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] coding standard question
Erik de Castro Lopo wrote: Vasili I. Galchin wrote: I am working with some existing code. where/let functions use the same name for function parameters as the outer function and hence there is a shadow warning from the compiler. To me it doesn't see totally unreasonable to code like this the downside is the nasty ghc warnings. Is there a coding consensus on this issue? I'm relatively new to Haskell, but I know that in imperative languages like C, a small percentage of shadow warnings are often real bugs and hence always worth fixing if possible (sometimes the problem is in system header files and hence can't be fixed). In Haskell there is an easy way around this. Variables can be name a, a', a'' and so on. Since these aid in clarity without forcing you to think up new variable names, I would suggest that its a good idea to fix these warnings. Speaking from experience it's good to fix all warnings, since otherwise there will be enough of them to cause a few terminal pages to scroll by when you compile and then there's a real danger of not noticing real errors. I'd pass '-Wall -Werror' to ghc to force myself to do this :-) Also from experience, I get a good feeling about software that compiles without warnings. It suggests the author cares and is indicative of some level of quality. /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
