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
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
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
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 ...
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
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
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
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
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
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
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,
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
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
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
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,
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
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
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
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.
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
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
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!
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
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
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
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
26 matches
Mail list logo
