(Pattern) Guards in lambdas
since Pattern Guards appear to be popular with the committee, I suggest to revisit the decision to drop guards from lambdas: (a) http://www.cse.unsw.edu.au/~dons/haskell-1990-2000/msg00353.html (b) http://www.cse.unsw.edu.au/~dons/haskell-1990-2000/msg00382.html 1. I disagree that this was a simplification of Haskell the language became smaller (fewer valid programs), but that reduction in size was bought by breaking a symmetry (pattern matches are the same whereever they are used) and adding a restriction (no guards for patterns in lambdas), so the smaller language is actually more complicated. 2. adding guards to lambdas can only cause more program runs to fail (no chance of handling pattern-match/guard failure and fall through), so it is kind of understandable that this feature was considered dubious. however, - adding a guard there is comparable to adding an assertion, a feature often considered valuable - with pattern guards, the guard is no longer restricted to filtering, and that added functionality is not currently accessible for lambda patterns suggestion: undo removal of guards from lambdas, especially (but not only) if pattern guards make it into the language. claus ps. are there any notes regarding the discussion and stylistic grounds mentioned in (a)?
"Claus Reinke"
since Pattern Guards appear to be popular with the committee, I suggest to revisit the decision to drop guards from lambdas:
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 Regards, Malcolm
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..
haskell-prime-bounces@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
On Thu, Oct 19, 2006 at 12:55:48PM +0100, Simon Marlow wrote:
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.
I think I would like to allow a (single) guard on a lambda. for assertion checking, I am a sucker for assertion checking and the more lightweight the better when it comes to that sort of thing. John -- John Meacham - ⑆repetae.net⑆john⑈
John Meacham wrote:
On Thu, Oct 19, 2006 at 12:55:48PM +0100, Simon Marlow wrote:
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.
I think I would like to allow a (single) guard on a lambda. for assertion checking, I am a sucker for assertion checking and the more lightweight the better when it comes to that sort of thing.
I like idea of a single guard on a lambda as well. I think it simplifies the language (slightly) by eliminating a special case where patterns are allowed but guards are not. - Ravi
participants (6)
-
Bulat Ziganshin -
Claus Reinke -
John Meacham -
Malcolm Wallace -
Ravi Nanavati -
Simon Marlow