[antlr-interest] rewrite rule element cardinality

[Terence Parr]

On Feb 23, 2010, at 1:50 PM, joestelmach at gmail.com wrote:

> Thank you for the fast replies.
> 
> Terence - I'm not sure if this will help, but here's a portion of the generated parser for rewrite rule ^( GROUP c option )
> 
> while ( stream_option.hasNext()||stream_c.hasNext() ) {
>  // Test.g:15:26: ^( GROUP c option )
>  {
>    Object root_1 = (Object)adaptor.nil();
>    root_1 = (Object)adaptor.becomeRoot((Object)adaptor.create(GROUP, "GROUP"), root_1);
> 
>    adaptor.addChild(root_1, stream_c.nextTree());
>    adaptor.addChild(root_1, stream_option.nextTree());
>    adaptor.addChild(root_0, root_1);
>  }
> }

that *looks* ok. to

> 
> When debugging test input "c a b", this code is executed twice (as expected.)  On the first iteration, stream_c.nextTree().children = [FOO, BAR], and stream_option.nextTree().token = BAZ, but on the second iteration, stream_c.nextTree().children already has the BAZ token ([FOO, BAR, BAZ],) and stream_option.nextTree().token=BAZ.

Ack! perhaps that I did not take into account flat trees...i'll bet that is it. To confirm this, can you change 'c' to just FOO? If that works, then I know exactly what the problem is.

> Gavin - referencing the array of options from a label doesn't seem to change anything.  As for your possible workaround, is it valid to reference a parameter directly in a rewrite rule?  I was under the impression that you could only reference rule parameters within target code blocks.

Correct but you can have action blocks within the tree rewrites.
Ter