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

[Thomas Jäger]

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

[Moving the discussion from the wiki to the mailing list until we've
reached some kind of consensus]

ad n+k-patterns
This old discussion seems kind of relevant.
http://www.dcs.gla.ac.uk/mail-www/haskell/msg01131.html

In my opinion, there's no reason to avoid (n+1)-patterns. Recursion is
the natural definition of many functions on the natural numbers, just
like on lists, trees or any other ADT. There just happens to be a more
efficient representation of naturals than as Peano numbers. There are
indeed circumstances where
> foo (n+1) = ... n ... n ... n ...
is much clearer than
> foo n = let n' = n + 1 in n' `seq` ... n' ... n' ... n' ...
On the wiki, you claim
> data Natural = Zero | Successor Natural
> They are implemented using binary numbers and it is not even tried to 
> simulate the behaviour of Natural (e.g. laziness). Thus I wouldn't state, that 3 > matches the pattern 2+1.
If however, you had defined
> data Nat = Zero | Succ !Nat,
pattern matching would still be possible, but Nat would behave exactly
as the (n+1) - pattern.

ad guards
I agree that guards are not always the right way to do it (as in the
example you mentioned on the wiki which was bad Haskell code anyway).
However, they have valid uses that can't be easily/naturally expressed
without them. A typical example might be
> foo (App e1 e2) | e1 `myGuard` e2 = App (foo e1) (foo e2)
> foo (Lambda v e) = Lambda v (foo e)
> foo (App e1 e2) = App (bar e1) (bar e2)
> ... 

So instead of saying "guards are bad", i think there should rather be
an explanation when guards are appropriate.

Altogether, the spirit of the page seems to be "use as little
syntactic sugar as possible" which maybe appropriate if it is aimed at
newbies, who often overuse syntactic sugar (do-notation). However, I
like most of the syntactic sugar provided by Haskell/Ghc, and it is
one reason why Haskell is such nice language, so I don't think we
should advocate unsugaring all our programs.

Thomas