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
