On 16 aug 2007, at 13.46, Bertram Felgenhauer wrote:
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.
.\ x y z -> ... a b c -> ... or just require unicode \lambda ;)