Guards and Case Expressions

A guard is a boolean condition attached to a function equation with a pipe |, evaluated top to bottom until one succeeds — bmiCategory bmi | bmi <= 18.5 = "Underweight" | bmi <= 25.0 = "Normal" | bmi <= 30.0 = "Overweight" | otherwise = "Obese" reads far more clearly than an equivalent chain of nested if-then-else expressions. The otherwise guard is simply defined as True in the Prelude, so it always matches and conventionally serves as the final catch-all branch; omitting it risks a runtime pattern-match failure if none of the earlier guards succeed and there's no other equation to fall back on. Guards can be attached to any function equation, not just simple ones, and can reference variables bound by the pattern on the left-hand side, as in classify (x:_) | x > 0 = "positive", combining structural matching with a boolean test in one clause.

A case expression matches a value against a series of patterns and evaluates the first one that fits, and unlike a chain of function equations, it can be embedded inline anywhere an expression is expected: describeNum n = case n of 0 -> "zero"; _ | n < 0 -> "negative"; _ -> "positive" shows a case with a pattern guard combining structural matching with a boolean condition on the same branch. Because case is itself an expression (it produces a value), it composes naturally inside let, inside another function call's argument position, or as the body of a do block step, whereas separate top-level function equations can only be used at a function's own definition site. When every branch of a case needs the same boolean logic but no interesting structural pattern, plain if-then-else or guards on a function equation are often more idiomatic than forcing a case with True -> / False -> branches.

As a rule of thumb, reach for pattern matching (multiple equations or case) when the logic depends on a value's structure — which constructor it is, whether a list is empty — and reach for guards when the logic depends on an arbitrary boolean condition over already-bound variables, like numeric ranges or comparisons. Plain if-then-else still has its place for a single two-way branch inside an expression, such as let status = if score >= 60 then "Pass" else "Fail", and is arguably clearer than a case with only True/False branches for a simple binary decision. Mixing all three appropriately — pattern matching for shape, guards for conditions, if for simple binary choices — tends to produce Haskell code that reads close to how a domain expert would describe the logic in plain English, rather than code cluttered with redundant boolean checks.