changes_from_133_before_mr13.txt
来自「EFI BIOS是Intel提出的下一代的BIOS标准。这里上传的Edk源代码是」· 文本 代码 · 共 1,543 行 · 第 1/5 页
TXT
1,543 行
files before any other #include statements required by pccts.
The only things before the #first text are comments and
a #define ANTLR_VERSION.
Requested by and Esa Pulkkinen (esap@cs.tut.fi) and Alexin
Zoltan (alexin@inf.u-szeged.hu).
#125. (Changed in 1.33MR11) Lookahead for (guard)? && <<p>>? predicates
When implementing the new style of guard predicate (Item #113)
in 1.33MR10 I decided to temporarily ignore the problem of
computing the "narrowest" lookahead context.
Consider the following k=1 grammar:
start : a
| b
;
a : (A)? && <<pred1(LATEXT(1))>>? ab ;
b : (B)? && <<pred2(LATEXT(1))>>? ab ;
ab : A | B ;
In MR10 the context for both "a" and "b" was {A B} because this is
the first set of rule "ab". Normally, this is not a problem because
the predicate which follows the guard inhibits any ambiguity report
by antlr.
In MR11 the first set for rule "a" is {A} and for rule "b" it is {B}.
#124. A Note on the New "&&" Style Guarded Predicates
I've been asked several times, "What is the difference between
the old "=>" style guard predicates and the new style "&&" guard
predicates, and how do you choose one over the other" ?
The main difference is that the "=>" does not apply the
predicate if the context guard doesn't match, whereas
the && form always does. What is the significance ?
If you have a predicate which is not on the "leading edge"
it is cannot be hoisted. Suppose you need a predicate that
looks at LA(2). You must introduce it manually. The
classic example is:
castExpr :
LP typeName RP
| ....
;
typeName : <<isTypeName(LATEXT(1))>>? ID
| STRUCT ID
;
The problem is that isTypeName() isn't on the leading edge
of typeName, so it won't be hoisted into castExpr to help
make a decision on which production to choose.
The *first* attempt to fix it is this:
castExpr :
<<isTypeName(LATEXT(2))>>?
LP typeName RP
| ....
;
Unfortunately, this won't work because it ignores
the problem of STRUCT. The solution is to apply
isTypeName() in castExpr if LA(2) is an ID and
don't apply it when LA(2) is STRUCT:
castExpr :
(LP ID)? => <<isTypeName(LATEXT(2))>>?
LP typeName RP
| ....
;
In conclusion, the "=>" style guarded predicate is
useful when:
a. the tokens required for the predicate
are not on the leading edge
b. there are alternatives in the expression
selected by the predicate for which the
predicate is inappropriate
If (b) were false, then one could use a simple
predicate (assuming "-prc on"):
castExpr :
<<isTypeName(LATEXT(2))>>?
LP typeName RP
| ....
;
typeName : <<isTypeName(LATEXT(1))>>? ID
;
So, when do you use the "&&" style guarded predicate ?
The new-style "&&" predicate should always be used with
predicate context. The context guard is in ADDITION to
the automatically computed context. Thus it useful for
predicates which depend on the token type for reasons
other than context.
The following example is contributed by Reinier van den Born
(reinier@vnet.ibm.com).
+-------------------------------------------------------------------------+
| This grammar has two ways to call functions: |
| |
| - a "standard" call syntax with parens and comma separated args |
| - a shell command like syntax (no parens and spacing separated args) |
| |
| The former also allows a variable to hold the name of the function, |
| the latter can also be used to call external commands. |
| |
| The grammar (simplified) looks like this: |
| |
| fun_call : ID "(" { expr ("," expr)* } ")" |
| /* ID is function name */ |
| | "@" ID "(" { expr ("," expr)* } ")" |
| /* ID is var containing fun name */ |
| ; |
| |
| command : ID expr* /* ID is function name */ |
| | path expr* /* path is external command name */ |
| ; |
| |
| path : ID /* left out slashes and such */ |
| | "@" ID /* ID is environment var */ |
| ; |
| |
| expr : .... |
| | "(" expr ")"; |
| |
| call : fun_call |
| | command |
| ; |
| |
| Obviously the call is wildly ambiguous. This is more or less how this |
| is to be resolved: |
| |
| A call begins with an ID or an @ followed by an ID. |
| |
| If it is an ID and if it is an ext. command name -> command |
| if followed by a paren -> fun_call |
| otherwise -> command |
| |
| If it is an @ and if the ID is a var name -> fun_call |
| otherwise -> command |
| |
| One can implement these rules quite neatly using && predicates: |
| |
| call : ("@" ID)? && <<isVarName(LT(2))>>? fun_call |
| | (ID)? && <<isExtCmdName>>? command |
| | (ID "(")? fun_call |
| | command |
| ; |
| |
| This can be done better, so it is not an ideal example, but it |
| conveys the principle. |
+-------------------------------------------------------------------------+
#123. (Changed in 1.33MR11) Correct definition of operators in ATokPtr.h
The return value of operators in ANTLRTokenPtr:
changed: unsigned ... operator !=(...)
to: int ... operator != (...)
changed: unsigned ... operator ==(...)
to: int ... operator == (...)
Suggested by R.A. Nelson (cowboy@VNET.IBM.COM)
#122. (Changed in 1.33MR11) Member functions to reset DLG in C++ mode
void DLGFileReset(FILE *f) { input = f; found_eof = 0; }
void DLGStringReset(DLGChar *s) { input = s; p = &input[0]; }
Supplied by R.A. Nelson (cowboy@VNET.IBM.COM)
#121. (Changed in 1.33MR11) Another attempt to fix -o (output dir) option
Another attempt is made to improve the -o option of antlr, dlg,
and sorcerer. This one by JVincent (JVincent@novell.com).
The current rule:
a. If -o is not specified than any explicit directory
names are retained.
b. If -o is specified than the -o directory name overrides any
explicit directory names.
c. The directory name of the grammar file is *not* stripped
to create the main output file. However it is stil subject
to override by the -o directory name.
#120. (Changed in 1.33MR11) "-info f" output to stdout rather than stderr
Added option 0 (e.g. "-info 0") which is a noop.
#119. (Changed in 1.33MR11) Ambiguity aid for grammars
The user can ask for additional information on ambiguities reported
by antlr to stdout. At the moment, only one ambiguity report can
be created in an antlr run.
This feature is enabled using the "-aa" (Ambiguity Aid) option.
The following options control the reporting of ambiguities:
-aa ruleName Selects reporting by name of rule
-aa lineNumber Selects reporting by line number
(file name not compared)
-aam Selects "multiple" reporting for a token
in the intersection set of the
alternatives.
For instance, the token ID may appear dozens
of times in various paths as the program
explores the rules which are reachable from
the point of an ambiguity. With option -aam
every possible path the search program
encounters is reported.
Without -aam only the first encounter is
reported. This may result in incomplete
information, but the information may be
sufficient and much shorter.
-aad depth Selects the depth of the search.
The default value is 1.
The number of paths to be searched, and the
size of the report can grow geometrically
with the -ck value if a full search for all
contributions to the source of the ambiguity
is explored.
The depth represents the number of tokens
in the lookahead set which are matched against
the set of ambiguous tokens. A depth of 1
means that the search stops when a lookahead
sequence of just one token is matched.
A k=1 ck=6 grammar might generate 5,000 items
in a report if a full depth 6 search is made
with the Ambiguity Aid. The source of the
problem may be in the first token and obscured
by the volume of data - I hesitate to call
it information.
When the user selects a depth > 1, the search
is first performed at depth=1 for both
alternatives, then depth=2 for both alternatives,
etc.
Sample output for rule grammar in antlr.g itself:
+---------------------------------------------------------------------+
| Ambiguity Aid |
| |
| Choice 1: grammar/70 line 632 file a.g |
| Choice 2: grammar/82 line 644 file a.g |
| |
| Intersection of lookahead[1] sets: |
| |
| "\}" "class" "#errclass" "#tokclass" |
| |
| Choice:1 Depth:1 Group:1 ("#errclass") |
| 1 in (...)* block grammar/70 line 632 a.g |
| 2 to error grammar/73 line 635 a.g |
| 3 error error/1 line 894 a.g |
| 4 #token "#errclass" error/2 line 895 a.g |
| |
| Choice:1 Depth:1 Group:2 ("#tokclass") |
| 2 to tclass grammar/74 line 636 a.g |
| 3 tclass tclass/1 line 937 a.g |
| 4 #token "#tokclass" tclass/2 line 938 a.g |
| |
| Choice:1 Depth:1 Group:3 ("class") |
| 2 to class_def grammar/75 line 637 a.g |
| 3 class_def class_def/1 line 669 a.g |
| 4 #token "class" class_def/3 line 671 a.g |
| |
| Choice:1 Depth:1 Group:4 ("\}") |
| 2 #token "\}" grammar/76 line 638 a.g |
| |
| Choice:2 Depth:1 Group:5 ("#errclass") |
| 1 in (...)* block grammar/83 line 645 a.g |
| 2 to error grammar/93 line 655 a.g |
| 3 error error/1 line 894 a.g |
| 4 #token "#errclass" error/2 line 895 a.g |
| |
| Choice:2 Depth:1 Group:6 ("#tokclass") |
| 2 to tclass grammar/94 line 656 a.g |
| 3 tclass tclass/1 line 937 a.g |
| 4 #token "#tokclass" tclass/2 line 938 a.g |
| |
| Choice:2 Depth:1 Group:7 ("class") |
| 2 to class_def grammar/95 line 657 a.g |
| 3 class_def class_def/1 line 669 a.g |
| 4 #token "class" class_def/3 line 671 a.g |
| |
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?