[antlr-interest] Guarded Predicates

Terence Parr parrt at jguru.com
Fri Dec 13 17:35:08 PST 2002


Houston...we have a problem with guarded predicates....um...they don't 
exist in the antlr.g grammar!  I'll look back at the revision history 
to see if I ever had that in there. :(  Ugh.  Anyway, it looks like 
ANTLR is generating incorrectly a syn pred.  The guard should be a 
simple set of tokens to check before evaluating the pred.

I'll let you know what I dig up.

Ter

On Friday, December 13, 2002, at 02:14  PM, David Ewing wrote:

> on 12/13/02 11:33 AM, Terence Parr at parrt at jguru.com wrote:
>
>> Yeah, I have a note to look into this...are you using Java output?
>> Does it look like ANTLR generates something for the guard?
>
> David's using C++ output (your favorite ;-). I've got an example of 
> what
> looks like bogus code to me too. I'll send it to you off-line.
>
> Dave
>
>>
>> On Friday, December 13, 2002, at 06:42  AM, David Wigg wrote:
>>
>>> Guarded predicates do not appear to do what I expected from them
>>> as described in the ANTLR documentation (which seemed sensible
>>> and intuitively correct).
>>>
>>> It says the following;
>>>
>>> ANTLR provides a guarded predicate to allow you to specify the
>>> lookahead context under which a predicate should be evaluated.
>>> The syntax is:
>>>
>>> (lookahead-context-for-predicate)=>{predicate}?
>>>
>>> A guarded predicate is useful in situations where the semantic
>>> predicate should be hoisted into the prediction decision only
>>> when the lookahead is consistent with some context. For example:
>>>
>>> a   :   (ID)=>{isType(LT(1))}? (ID|INT)
>>>      |   ID
>>>      ;
>>>
>>> Here, the predicate is only applicable when an ID is found on
>>> the input stream. It should not be evaluated when an INT is found.
>>>
>>>
>>> So, in the case illustrated above if an INT was next the guarded
>>> predicate would not be evaluated and parsing would continue
>>> within the first alternative to (ID|INT).
>>>
>>> In fact as far as I can see the effect of the current
>>> implementation is that unless the predicate is true parsing will
>>> not fall through to the rest of the alternative anyway.
>>>
>>> It's quite simple to put the above rule in a .g file to compile
>>> it and to examine the resulting generated code.
>>>
>>> I find it rather ominous that I have only been able to find any
>>> examples of guarded predicates in TinyBasic.g in the java
>>> examples. Does this mean that other people have found that
>>> guarded predicates don't work?
>>>
>>> Needless to say I have not found anything about this in the
>>> FAQs. "No results found" was the response to a search for "Guarded".
>>>
>>> David.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> abstract_declarator
>>>    :  (SCOPE|ID)=> {qualifiedItemIsOneOf(qiPtrMember)}?
>>>       ptr_operator abstract_declarator {declaratorPointerTo();}
>>>    |  LPAREN abstract_declarator RPAREN
>>>       (abstract_declarator_suffix)+
>>>    |  (LSQUARE (constant_expression )? RSQUARE  {declaratorArray();}
>>>       )+
>>>    |  /* empty */
>>>    ;
>>>
>>>
>>>
>>>
>>> Your use of Yahoo! Groups is subject to
>>> http://docs.yahoo.com/info/terms/
>>>
>>>
>> --
>> Co-founder, http://www.jguru.com
>> Creator, ANTLR Parser Generator: http://www.antlr.org
>> Lecturer in Comp. Sci., University of San Francisco
>>
>>
>>
>>
>> Your use of Yahoo! Groups is subject to 
>> http://docs.yahoo.com/info/terms/
>>
>>
>>
>
>
>
>
> Your use of Yahoo! Groups is subject to 
> http://docs.yahoo.com/info/terms/
>
>
--
Co-founder, http://www.jguru.com
Creator, ANTLR Parser Generator: http://www.antlr.org
Lecturer in Comp. Sci., University of San Francisco


 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 



More information about the antlr-interest mailing list