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
On Mon, Jun 29, 2009 at 3:41 PM, Daniel Fischer 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 sa
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-pri
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
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
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
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 maintai
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
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 advis
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!
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
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
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:
> :1:34: Warning: Defined but not used: `a''
Clearly I simplified the example too far. Try this, only slig
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
On Mon, Jun 22, 2009 at 12:06 PM, Malcolm Wallace <
malcolm.wall...@cs.york.ac.uk> wrote:
> 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
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
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''
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
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 wa
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 notic
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:
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 t
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 th
2009/6/22 Vasili I. Galchin :
> 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
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 i
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.
26 matches
Mail list logo
