Duncan Coutts wrote:
On Wed, 2007-08-15 at 11:06 -0700, Stefan O'Rear wrote:
foo = getSomethingCPS $ \ arg -> moreStuff
is now a syntax error (\ { varid -> } matches no productions).
I'm not sure I follow.
The patterns would have to match up in a column, so
foo = getSomethingCPS $ \ arg -> moreStuff
should be fine, to add another alternative it'd have to be:
foo = getSomethingCPS $ \ Pat1 -> moreStuff Pat2 -> evenMoreStuff
I don't like this - it's not in the spirit of the existing layout rule at all. You should have to indent 'moreStuff' deeper than Pat1 I think;
foo = getSomethingCPS $ \ Pat1 -> moreStuff Pat2 -> evenMoreStuff
would be (visually) ok. But then Stefan's point is valid. So there should be two productions, I think, one for non-case lambdas and one for case-lambdas, like this: non-case-lambda: '\' apat+ '->' expr case-lambda: '\' '{' ( apat+ '->' expr ';' )* '}' Unfortunately this naive approach would add another point of arbitrarily large look-ahead to the grammar. The easiest way to resolve this is to add some keyword before or after '\', bringing is back to the previous proposals. I like both \of x y z -> ... a b c -> ... and case \ of x y z -> ... a b c -> ... (I'd add the space here, viewing \ as a pseudo-expression) In the spirit of the \\ proposal, while \\ itself is an operator, \ \ x y z -> ... a b c -> ... is still available as a syntax, but may be confusing. I have little preference between these options. Bertram