[antlr-interest] Bug? Invalid Java code generated

[Terence Parr]

Hi Guys,quikly scanning...$text means text for entire rule; if hoisted  
out of rule it makes no sense. sem predicates should only use  
functions of input.LT(i) if they get hoisted.
Ter
On Mar 6, 2009, at 11:55 AM, Johannes Luber wrote:

> Sam Barnett-Cormack schrieb:
>> Andreas Meyer wrote:
>>> Sam Barnett-Cormack schrieb:
>>>> If this isn't a bug, can someone explain how to pass a function  
>>>> called
>>>> in a predicate the text matched so far? If this is a bug, anyone  
>>>> have
>>>> a workaround? Please. Thanks!
>>> I'm currently not 100% sure of the exact syntax, but why dont you  
>>> use
>>> something like $nameForm.text ? This is the simplest workaround  
>>> for the
>>> problem you showed. Or do you have other cases where you need to  
>>> easily
>>> access the $text of a lot of rules?
>>
>> Yeah, that's what I just figured from looking at examples - it's not
>> made completely clear, and if it weren't for the fact that it  
>> generates
>> *some* code that's *almost* right, I might have realised it sooner.
>
> Well, the docs say "attribute". With the exceptions of .NETs
> "attributes" this does tell that you have to use an operator to bind
> "text" to an object. Considering that chapter 6 does explain both
> variants in depth - especially 6.4 - I can neither fault Ter nor the  
> book.
>
> What is strange though is that both variants are supposed to be
> equivalent and reading through the chapter has offered a clue why the
> abbreviation doesn't work here. Hoisting doesn't seem to be the  
> problem.
> Ter, can you please shed light on this matter?
>
> Johannes
>>
>> Of course, I can't try it right now, because that computer has  
>> decided
>> it doesn't want to play...
>>
>
> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address