(&&)
, which I thought was mildly unintuitive:(&&) :: Bool -> Bool -> Bool True && y = y _ && _ = False
The reason I found this definition odd is that the author chose to use a wildcard (the first underscore in the second line) instead of the explicit data
False
. Since Bool
only has two choices, True
and False
, I think explicitly using False
instead is more intuitive, since I had to think about the other values that the wildcard can take on besides False
. Furthermore, the Haskell compiler, ghc
, will validate whether all patterns are matched in the function definition.Thus, I would rewrite the function as:
True && y = y False && _ = False
*
Additional commentary:
Brian Hamrick likes when the wildcard is conceptually a catch-all, i.e.:
True && True = True _ && _ = False
At first, I thought this best describes the logical truth table, where the only
True
result is from the inputs (True, True)
. However, this changes the laziness properties of the function in Haskell: the second argument is forced to evaluate when the first one is True since we do not have enough information to match (AN: this was not obvious to me at first). If the second argument is True, then we match the first line; otherwise, we match the second line, so the second argument gets reduced to weak head normal form (WHNF).*
Thanks to Brian Hamrick for help with this expository post.