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