On Feb 23, 2010, at 1:50 PM, [email protected] 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 List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address -- You received this message because you are subscribed to the Google Groups "il-antlr-interest" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/il-antlr-interest?hl=en.
