27 March 2000 Release 2.22 Notes for New Users of PCCTS Version 1.33MR22
24
#119. Syntactic predicates should not have side-effects
If there is no match then the rule which uses the syntactic predicate won't be executed.
#120. How to use init-actions to create side-effects in guess mode (despite Item #119)
If you absolutely have to have side-effects from syntactic predicates one can exploit the fact that
ANTLR
always
executes init-actions, even in guess mode:
rule : (prefix)? A
| B
;
prefix : <<
regular-init-action-that's-always-executed
>>
A ( <<
init-action-for-empty-subrule
>> ) B
;
The init-actions in "prefix" will always be executed (perhaps several times) in guess-mode. Contributed by TJP.
#121. With values of
k
>1 or infinite lookahead mode one cannot use feedback from parser to lexer
As infinite lookahead mode can cause large amounts of the input to be scanned by
DLG
before
ANTLR
begins parsing
one cannot depend on feedback from the parser to the lexer to handle things like providing special token codes for
items which are in a symbol table (the "lex hack" for
typedefs
in the C language). Instead one
must
use semantic
predicates which allow for such decisions to be made by the parser or place such checks in the
ANTLR
TokenBuffer
routine getToken() which is called every time the parser needs another token. See Example #10.
#122. Can't use interactive scanner (
ANTLR
­gk option) with
ANTLR
infinite lookahead
#123. Syntactic predicates are implemented using setjmp/longjmp - beware C++ objects requiring destructors
Semantic Predicates
#124. Semantic predicates have higher precedence than alternation:
<<>>? A|B
means
(<<>>? A)|B
#125. Get rid of warnings about missing LT(i) by using a comment:
/* LT(i) */
#126. It is sometime desirable to use leading actions to inhibit hoisting of semantic predicates
#127. Any actions (except init-actions) inhibit the hoisting of semantic predicates
Here is an example of an empty leading action whose sole purpose is to inhibit hoisting of semantic predicates
appearing in rule2 into the prediction for rule1. Note the presence of the empty init-action (See Item #108).
rule1 : <<;>> <<>> rule2
| rule3
;
rule2 : <<semanticPred(LT(1)->getText())>>? ID ;
#128. Semantic predicates that use local variables or require init-actions must inhibit hoisting
#129. Semantic predicates that use inheritance variables must not be hoisted
You cannot use downward inheritance to pass parameters to semantic predicates which are
not
validation
predicates. The problem appears when the semantic predicate is hoisted into a parent rule to predict which rule to
call:
For instance:
a : b1 [flag]
| b2
;
b1 [int flag]
: <<flag && hasPropertyABC(LT(1)->getText())>>? ID ;
b2 : ID ;
When the semantic predicate is evaluated within rule "a" to determine whether to call b1, b2, or b3 the compiler will
discover that there is no variable named "flag" for procedure "a()". If you are unlucky enough to have a variable
named "flag" in a() then you will have a
very
difficult-to-find bug.
#130. A semantic predicate which is not at the left edge of a rule becomes a validation predicate