[antlr-interest] Bug? Invalid Java code generated

[Terence Parr]

On Mar 6, 2009, at 2:02 PM, Sam Barnett-Cormack wrote:

> Terence Parr wrote:
>> 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.
>
> So can I replace
>
> objIdComponents options{backtrack=true;}
>  : nameForm {isStandardOIDName($text)}?
>  | numberForm
>  | nameAndNumberForm
>  | definedValue
>  ;
>
> with
>
> objIdComponents options{backtrack=true;}
>  : nameForm {isStandardOIDName($nameForm.text)}?
>  | numberForm
>  | nameAndNumberForm
>  | definedValue
>  ;
>

Well, that won't behoisted into any decisions.

you need

: {isStandardOIDName(input.LT(1).getText())}? nameForm

T

> or do I have to actually make nameForm return a String or something?  
> Bearing in mind that I can't test at the moment because the computer  
> that that work is one decided to be difficult...
>
> Sam
>
>> 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
>
>
> -- 
> Sam Barnett-Cormack