[Clarify potential pattern matching pitfalls. Bryan O'Sullivan **20070919185247] { hunk ./en/ch03-funcs-types.xml 1353 - Limits to pattern matching + Early pattern matching pitfalls hunk ./en/ch03-funcs-types.xml 1355 - Every variable that appears within a pattern is a new - local variable that will be given a value if the pattern - matches, not a reference to some variable on - outside the pattern. Matching a pattern only - lets us do exact comparisons against constructors and simple - values. We can't use a pattern to match something like a - function. To see what we mean, take a look at the following - function. + There are a few ways in which new Haskell programmers can + misunderstand or misuse patterns. Here are a few potential + missteps that you can easily avoid. + + There's no way to write a pattern that compares + a value with a variable. Matching a pattern only lets us + perform exact comparisons against combinations of constructors + and simple values. + + Here's a well-intentioned example of pattern matching gone + awry. This code compiles cleanly, but depending on what you + expect it to do, it might surprise you. hunk ./en/ch03-funcs-types.xml 1370 - A naive glance suggests that it's trying to check the - value of f to see if it's actually the - standard function head, but such an - interpretation would be quite wrong. Here's what is - really doing. + A naive glance suggests that this code is trying + to check the value of f to see if it's + actually the standard function head, but + here's what it is really doing. hunk ./en/ch03-funcs-types.xml 1375 - Because the first pattern in the case - expression is just a variable, this pattern will - always match, no matter what the value of - f is, and the value of f - will be given to the local variable head - when the right hand side is evaluated. + Because the first pattern in the + case expression is a variable, this branch of the + case will always match, no + matter what the value of f is. The name + head thus acts as a local variable whose + value is the value of f, which hides the + global definition of the well-known head + function. hunk ./en/ch03-funcs-types.xml 1385 + Irrefutable patterns + hunk ./en/ch03-funcs-types.xml 1388 - match, because it's not being compared against anything that - might cause the match to fail. We refer to patterns that + match, because it's not being compared against any value that + could cause the match to fail. We refer to patterns that hunk ./en/ch03-funcs-types.xml 1393 - Finally, because the first pattern always matches, &GHC; - will always evaluate its right hand side and use that as the - result of the case expression. The second - pattern (the one with the wild card) will never actually be - reached. Because the two patterns will match the same values, - they are said to overlap. If &GHC; ever - complains to you about overlapping patterns, it's telling you - that one of your patterns is the same as another, and so will - never actually be matched. + The first pattern always matches, because it's + irrefutable. But the second pattern also + always matches, because it uses a wild card. However, because + Haskell attempts to match patterns in the order in which we + write them, the first pattern will always succeed, and the + second pattern will never actually be reached. Because the two + patterns will match the same values, they are said to + overlap. If &GHC; ever complains to you + about overlapping patterns, it's telling you that one of your + patterns is the same as another, and so it will never actually + be matched. hunk ./en/ch03-funcs-types.xml 1405 - Another limitation of patterns is that a variable can only - appear once in a pattern. For example, you can't put a - variable in multiple places within a pattern to express the + Another thing to be aware of is that a variable + can only appear once in a pattern. For example, we can't put + a variable in multiple places within a pattern to express the }