(Pattern) Guards in lambdas
simonmar at microsoft.com
Thu Oct 19 07:55:48 EDT 2006
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
> 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
> 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.
More information about the Haskell-prime