Matching literal values
editExercises |
---|
|
1.
When used for pattern matching, a simple variable name like the k
in
h k = True
binds k
to the argument of h
and, crucially, matches anything at all. Since we are not using the bound k
variable in the right hand side of the equation, in this function the effect of this definition is the same of
h _ = True
Which is why GHC/GHCi complains about overlapping patterns, and why the second equation for h
gets ignored. Also, the k = 1
definition made outside of the function has no influence on what happens - the k
used in pattern matching has local scope (that of the h
equation), and has nothing to do with that other k
.
2.
Bool
is not a literal value; rather, it is an algebraic datatype like the ones we first met in the previous chapter. In essence, its definition in Prelude amounts to simply:
data Bool = False | True
False
and True
are parameterless constructors; and that is why their names start with a capital letter.
Syntax tricks
editExercises |
---|
Implement scanr , as in the exercise in Lists III, but this time using an as-pattern. |
myScanr step zero [] = [zero]
myScanr step zero (x:xs) = (step x y):ys
where ys@(y:_) = myScanr step zero xs
You probably used head
instead of an as-pattern in the first version of this exercise; here, on the other hand, we do not match the empty list in the pattern for ys
. In this specific case, neither solution is actually unsafe, because the result of myScanr
will never be an empty list. Nevertheless, pattern matching still is a better choice than head
, as it makes it more obvious that we chose not to handle the empty list case.