[Haskell] Replacing and improving pattern guards with PMC syntax

[kahl at cas.mcmaster.ca]

Brandon,

 > Both of these constructs amount to minor syntactical overloading, 
 > 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.)


Several of your suggestions, including

 > 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