# Pattern guards

Conor McBride ctm at Cs.Nott.AC.UK
Sat Sep 30 09:51:55 EDT 2006

```Claus Reinke wrote:
> If it wasn't for those pesky returns/guards, one might claim the
> translations
> to be as concise as the originals. As it stands, the results of the
> translation
> are rather more awkward but -and this is the important point- pattern
> guards do not add new functionality.

Well, neither do Boolean guards nor even basic pattern matching (with
respect to case expressions). I'm not necessarily in favour of pattern
guards exactly as formulated, but I am in favour of thinking about
syntax to support a more readable presentation of the scrutiny process
by which functions make choices. Things to minimise include

(1) Wiring: naming a thing in order to inspect it, as in

mygcd x y
| LT <- z   = mygcd x (y-x)
| GT <- z   = mygcd (x-y) y
where z = compare x y

mygcd x _ = x

The version I proposed

gcd x y | compare x y ->
LT = gcd x (y - x)
GT = gcd (x - y) y
gcd x _ = x

avoided the need for this indirection via z and the dislocation of
(compare x y) from the patterns which give it relevance. I want to
present a direct tabulation of patterns visibly headed by the expression
they analyse. It's far more comprehensible.

(2) Monadic noise: one simply should not need to clutter a program with
do, return, mplus and fromJust (ugh!), spelling out the semantics of
pattern matching in minute detail. For at least 36 years, we've been
able to hide all that junk behind a highly readable equational notation.
This is one monad we don't need to see.

(3) Early commitment to one particular right-hand side: without pattern
guards, we're forced to the right if we want to examine the result of an
intermediate computation. This means we have to do any subsequent
analysis using the syntax of expressions which is much clunkier than
that of left-hand sides. Pattern guards as proposed give us a bare
minimum, a one-shot match: more patterns require wiring. The notation I
suggested is a modest improvement, allowing multiple attempts to match,
but it's still not as general as it might be. If, for example, we wanted
to analyse one of the original pattern variables further, in the light
of a case on an intermediate value, we're stuffed.

In general, I'd like to be able to compact programs written with helper
functions, eg

gcd x y = help x y (compare x y) where
help 0 y LT = y
help x y LT = gcd x (y - x)
help x 0 GT = x
help x y GT = gcd (x - y) y
help x _ _ = x

Introducing the helper just adds an 'extra column' for (compare x y),
and then we can do what we like! I'd quite like to inline this a little.
Apologies for the wildly made-up notation

gcd x y | compare x y -> -- just introduces new column
gcd 0 y , LT          = y
gcd x y , LT          = gcd x (y - x)
gcd x 0 , GT          = x
gcd x y , GT          = gcd (x - y) y
gcd x _ , _           = x

I'd adopt the convention that omitting the

lhs,

just means the gets copied from left of the |, so we recover my earlier
notation as a special case, and we don't get punished for /not/
inspecting pattern variables further.

Yes, I know the example is contrived, but as David points out, it's hard
to come up with simple examples of phenomena which tend to bite in more
complex situations.

I'm guessing this is all too wild and woolly for haskell-prime, but I
thought I'd try to survey a bit more of the design space in the
interests of an effective compromise. All of these programs can be
turned into decision trees made from let and case-on-variable: the
question is to what extent we support the compression of these trees as
contingency tables for the sake of clarity. Do we give up at the first
let? At the first non-Boolean let? At the first let x not immediately
followed by some favoured pattern of case x? When?

The recodings of the pattern guard programs we've seen so far strike me
as eloquent arguments in favour of adopting at least the notion of
pattern guards from the original proposal.

All the best

Conor

This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

```