# [Haskell] Replacing and improving pattern guards with PMC syntax

kahl at cas.mcmaster.ca kahl at cas.mcmaster.ca
Mon Oct 2 15:33:37 EDT 2006

Brandon,

> allowing lambda and "case" constructs in the expression grammar and the
> match grammar with slightly different meanings. This seems to be pretty
> similar to the way we already allow (Constr x y z) as an expression or a
> pattern.

I'm afraid this could easily lead to ambiguity on the grammar level
and, independently, to confusion in the human head.
But if these issues can be resolved,
I currently do not feel strongly either way.

Note however that

> f xs = case xs of
>     (x : xs) -> case xs of
>                     (y : ys) -> 1
>     _        -> 2

and

> g xs = case xs of
>     (x : xs) -> match xs with
>                     (y : ys) -> 1
>     _        -> 2

are different:

f "01" = 1             g "01" = 1
f "0"  = undefined     g "0"  = 2
f ""   = 2             g ""   = 2

f is in Haskell 98, and g can be rewritten using pattern guards:

> g xs = case xs of
>     (x : xs) | (y : ys) <- xs   -> 1
>     _        -> 2

That is what I mean with ``fall-through'' --- and from this you see that
you need an indicator for whether what is coming after the ``->''
is a matching or an expression.

As long as the production

alt -> expr

is included, nothing that parses as an expression
can be allowed to also parse as a matching according to a different production.

In PMC, the corresponding production is

match -> \leftharpoonup expr \rightharpoonup

, so there, using ``case'' both for expressions and for matchings
would ``only'' be confusing...

But using delimiters is of course an option.
(I also considered a different arrow for one of the two cases,
for example ``|=>'' as in PMC, or even ``=>'',
but I thought that the delimiter-less option was more ``Haskell-ish'',
and with care in the grammar design can be made to work.)

> I suggested whitespace rather than -> to separate sequential patterns

could be feasible alternatives for the concrete syntax ---
but we first need agreement on the abstract syntax.

Perhaps the extension

alt -> "match" exp "with" { alts }

could be considered as an independent extension;
this is more powerful than pattern guards,
and probably less controversial than multi-alternative lambda.

Wolfram