(Pattern) Guards in lambdas

[Simon Marlow]

haskell-prime-bounces at haskell.org wrote:
>>> suggestion: undo removal of guards from lambdas, especially
>>> (but not only) if pattern guards make it into the language.
>> 
>> See the existing proposals
>>    http://hackage.haskell.org/trac/haskell-prime/wiki/LambdaCase
>>    http://hackage.haskell.org/trac/haskell-prime/wiki/MultiWayIf
> 
> thanks. I'm a fan of the correspondence principle, and as we have
> a LetCase, there should be a LambdaCase as well (the other seems
> to be inspired by Lisp's cond?). but the syntax is slightly awkward.
> is there a reason not to merge LambdaCase and Lambda, thus
> addressing both my suggestion and the LambdaCase proposal?
> 
>     f <pat> | <patguard> = <rhs>
> 
>     \ <pat> | <patguard> -> <rhs>
> 
>     case x of <arms>
> 
>     (\ <arms> ) x
> 
> claus
> 
> ps. strawpoll-2 has both LambdaCase and MultiWayIf as 'no'.
>     but that is numbers, not rationale..

I find LambdaCase quite distasteful, mostly for the same reason that the
'f _ x' syntax for a section is ugly: its just hard to read, because you
have to backtrack and re-read the expression when you figure out that
there was an implicit lambda lurking earlier.

MultiWayIf was my proposal, but I voted against it(!) mainly because (a)
it isn't implemented anywhere, and (b) I'm beginning to feel that we
don't *really* need any more syntax, at least not when the payoff is
small like this.

As for extending lambda to allow multiple guards and/or multiple pattern
matches, I don't think we need that either.  Lambda is a quiet syntax
and will be lost at the beginning of a sequence of pattern
matches/guards; it's best used for simple lambda expressions,
complicated pattern matches should be done using function equations.

Cheers,
	Simon