[Haskell-cafe] Things to avoid (Was: Top 20 ``things'' to know in Haskell)

[Remi Turk]

On Wed, Feb 09, 2005 at 02:54:12PM +0100, Henning Thielemann wrote:
> 
> On Wed, 9 Feb 2005, Henning Thielemann wrote:
> > Is there also a Wiki page about things you should avoid?
> 
> Since I couldn't find one, I started one on my own:
> 
> http://www.haskell.org/hawiki/ThingsToAvoid
> 
> I consider 'length', guards and proper recursion anchors.

Okay, I still definitely have some problems with the part about
guards, and I'm going on bothering you about it because it's The
HaWiki, and not just your site ;)

First of all, I rarely combine multiple-defs with guards, and
even more rarely omit an otherwise- or all-variables-and-no-guard
case, so I may just have avoided all stated problems that way.

Second, I don't have much experience with Haskell-newbies
(besides my own (hopefully) past and the ones on the mailing
lists), so my assumptions about common pitfalls may well be
wrong.

That said, the points I don't agree with:

1) It's talking about the compiler having difficulty with some
   warnings when using guards. In none of the examples given (the
   primes) I got any warnings, and from a quick made up example
   it appears that at least GHC is quite capable of detecting
   non-exhaustive patterns even when combining patterns and
   guards. In case you're talking about something like this:

       f x | odd x  = ...
           | even x = ...

   GHC does complain. I would also call it Bad Code,
   but if it's what you mean, _this_ example should be in the
   wiki. (As in: blahblah, it actually _is_ exhaustive, but in
   general requires solving the halting-problem to prove or
   something like that ;)

   Also, when compiling them (even _without_ optimizations) the
   three examples yield _exactly_ the same code, except for the
   fact that the if-then-else example moves the "n == 2"
   comparision to the RHS of the expression. This move can just
   as easy be done on the guarded version, which removes any
   difference in generated code/warnings.

2) foo xs | length xs == 1 = bar (head xs)
   As already said in "Don't ask for the length of a list, if you
   don't need it", this usage of length is bad in itself, and
   doesn't really help the argument against patterns IMO.

3) the pattern guards extension.
   I have two objections against this one. First, I don't think
   it's a good idea to talk about a non-standard extension like
   pattern guards in a wiki about newbie-problems. (Unless in the
   sense of "there are some compiler extensions which you
   probably won't need anytime soon.") Second, it's just horrible
   code: A useless violation of DRY (Don't Repeat Yourself).
   
Groeten,
Remi


P.S.   I _do_ agree with most of the other points ;)

P.P.S. Does a piece about "Avoid explicit lambda's" stand any
       chance of not being removed?
       (Basically about "\x y -> x + y" vs "(+)", and "when it
       gets more complicated it probably deserves a name.")

-- 
Nobody can be exactly like me. Even I have trouble doing it.