Pattern guards

[Conor McBride]

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.