
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.