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 :)

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

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

Jules Bean wrote: 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.

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'".

Jochem Berndsen wrote:

My default is to start developing, then adding -Wall -Werror and make it compile again.

That and hlint! Martijn.

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

Am Freitag 26 Juni 2009 11:30:32 schrieb david48:

On Thu, Jun 25, 2009 at 3:27 AM, wren ng thornton 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 ?

===================================== david@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 = "xxxxxxxx" , mysqlPassword = "xxxxxxxx" , mysqlDatabase = "xxxxxx" , 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

Am Montag 29 Juni 2009 10:47:05 schrieb david48:

Hello Daniel and all, Your suggestion #1 : Can't import Database.HDBC.MySQL.Connection :

david@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.

Erik de Castro Lopo 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

Johan Tibell 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

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/

2009/6/22 Malcolm Wallace :

Erik de Castro Lopo 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