Re: Groovy beta 10 released! (+JSR Early Access)

On 2 Mar 2005, at 18:29, Chris Poirier wrote:
> Hi Jochen,
>
>>>> what is the right tool, that allows closures to start in the next 
>>>> line?
>>>
>>> The right tool I was referring to was a parser generator that isn't 
>>> LL.
>>> LL isn't up to Groovy.
>>
>> It is not LR or LALR I think... what is it then?
>
> Frankly, I think LALR would have done a better job.  I haven't worked 
> it
> out for sure, but I'm pretty sure LALR could handle the | ambiguity in
> closure parameters without resorting to marking otherwise-valid-looking
> code as illegal.
>
>    myObj.myFunc { |x, y = 1 | 2, z = 0| x + y + z }
>
> I'm pretty sure LALR is capable of recognizing the 1 | 2 as an
> expression, whereas LL is going to read the | as the end of the
> parameter list, and then whine about 2 being a "dumb statement".

Irrespective of the parser technology used, there's still an ambiguity 
in there if we allow multiple assignment  (with a slight change to the 
statement, adding 'v' instead of 2)

Does that really mean

myObj.myFunc { |x, y = (1 | v), z = 0| x + y + z }

or

myObj.myFunc { |(x, y = 1) | v, z = 0| x + y + z }

FWIW to handle default values in closure syntax without ambiguity and 
using any valid groovy expression for the default value, the current 
parser enforces parens

e.g.

myObj.myFunc { (x, y = 1 | 2, z = 0)| x + y + z }

this is only required if you're using default argument values; if 
you're just using an argument list or typed argument list you can omit 
the parens.

James
-------
http://radio.weblogs.com/0112098/