# Re: Why I hate n+k

```Simon writes ...

| Just to amuse you all, here's a quick Haskell 98 quiz:
|
| 	What do the following definitions do:
|
| 1	x + 1 = f x
|
| 2	(x + 1) = f 2
|
| 3	(x + 1) * 2 = f x
|
| 4	(x + 1) 2 = g x
|
|
| That's right!
|
| (1) partially defines (+).  One could add more equations, thus:
| 	x + 1 = f x
| 	x + other = g x
|
| (2) is a pattern binding that binds x.  It's quite like
|
| 	Just x = f 2
|
|   except that the pattern is an n+k pattern
|
| (3) is a function binding rather like (1), except that it defines (*).
| The (*) operator has two operands: an n+k pattern (x+1) and 2.
|
| (4) is a new possibility in Haskell 98.
| It defines (+), albeit differently to (1).  Here the (+) has
| three operands, namely x, 1, and 2, so it will have a different
| type to the usual (+) but never mind.
|
|
| I don't propose to change this, because in practice it doesn't seem
| to cause much of a problem, but it seems pretty confusing.  To my mind
| the culprit is clear: n+k patterns.  But they are staying in Haskell 98.

Aaah, n+k patterns again. I am not ashamed to admit that I love n+k
patterns and that these examples do not really change my point of
view.  The major source of confusion is that n+k patterns are
admissible in pattern bindings which makes it hard to distinguish them
from function bindings defining `+' [(1) vs (2), (3) and (4) are
unambiguous]. Personally, I never use n+k pattern bindings but I do use
n+k patterns in functions bindings. Don't throw the baby out with the
water! If we strive for an unambiguos language which is BTW an
ambitious design goal let us nuke n+k pattern bindings but retain n+k
patterns in function bindings. On the negative side this adds an
irregularity to the language of patterns but one which I would be
willing to accept (in view of the advantages of n+k patterns).

Cheers, Ralf
```