Intel XENIX 286 Programmers Guide (86) - Tenox.tc
Intel XENIX 286 Programmers Guide (86) - Tenox.tc Intel XENIX 286 Programmers Guide (86) - Tenox.tc
XENIX Programming yacc: Compiler-Compiler Notice that, in addition to the actions for each state, there is a description of the parsing rules being processed in each state. The underscore character ( ) is used to indicate what has been seen and what is yet to come in each rule. Suppose the input is DING DONG DELL It is instructive to follow the steps of the parser while processing this input. Initially, the current state is state 0. The parser needs to refer to the input to decide between the actions available in state 0, so the first token, DING, is read, becoming the look-ahead token. The action in state 0 on DING is shift 3, so state 3 is pushed onto the stack, and the look-ahead token is cleared. State 3 becomes the current state. The next token, DONG, is read, becoming the look-ahead token. The action in state 3 on the token DONG is shift 6, so state 6 is pushed onto the stack, and the look-ahead is cleared. The stack now contains 0, 3, and 6. In state 6, without even consulting the look-ahead, the parser reduces by rule 2. sound : DING DONG This rule has two symbols on the right-hand side, so two states, 6 and 3, are popped off of the stack, uncovering state 0. Consulting the description of state 0, looking for a goto on sound sound goto 2 is obtained; thus state 2 is pushed onto the stack, becoming the current state. In state 2, the next token, DELL, must be read. The action is shift 5, so state 5 is pushed onto the stack, which now has 0, 2, and 5 on it, and the look-ahead token is cleared. In state 5, the only action is to reduce by rule 3. This has one symbol on the right-hand side, so one state, 5, is popped off, and state 2 is uncovered. The goto in state 2 on place, the left side of rule 3, is state 4. Now the stack contains 0, 2, and 4. In state 4, the only action is to reduce by rule 1. There are two sy mbols on the right, so the top two states are popped off, uncovering state 0 again. In state 0, there is a goto on rhyme causing the parser to enter state 1. In state 1, the input is read; the endmarker is obtained, indicated by $end in the y.output file. The action in state 1 when the endmarker is seen is to accept, successfully ending the parse. You should consider how the parser works when confronted with such incorrect strings as DING DONG DONG, DING DONG, DING DONG DELL DELL, etc. A few minutes spent with this and other simple examples will probably be repaid when problems arise in more complicated contexts. 10-13
yacc: Compiler-Compiler XENIX Programming Ambiguity and Conflicts A set of grammar rules is ambiguous if there is some input string that can be structured in two or more different ways. For example, the grammar rule expr : expr '-' expr is a natural way of expressing the fact that one way of forming an arithmetic expression is to put two other expressions together with a minus sign between them. Unfortunately, this grammar rule does not completely specify the way that all complex inputs should be structured. For example, if the input is expr - expr - expr the rule allows this input to be structured as either or as ( expr - expr ) - expr expr -(expr -expr ) (The first is called left association, the second right association}. yacc detects such ambiguities when attempting to build the parser. Consider the problem that confronts the parser when it is given an input such as expr -expr - expr When the parser has read the second expr, the input that it has seen expr - expr matches the right side of the gram mar rule above. The parser could reduce the input by applying this rule; after applying the rule, the input is reduced to expr (the left side of the rule}. The parser would then read the final part of the input - expr and again reduce. The effect of this is to take the left associative interpretation. Alternatively, when the parser has seen expr - expr it could defer the immediate application of the rule and continue reading the input until it had seen 10-14 expr -expr - expr
- Page 164 and 165: XENIX Programming csh: C Shell Usin
- Page 166 and 167: XENIX Programming csh: C Shell Usin
- Page 168 and 169: XENIX Programming csh: C Shell The
- Page 170 and 171: XENIX Programming csh: C Shell Note
- Page 172 and 173: XENIX Programming switch ( string c
- Page 174 and 175: XENIX Programming csh: C Shell Star
- Page 176 and 177: XENIX Programming csh: C Shell Spec
- Page 178 and 179: CHAPTER 9 lex : LEXICAL ANA LYZER G
- Page 180 and 181: XENIX Programming lex: Lexical Anal
- Page 182 and 183: XENIX Programming lex: Lexical Anal
- Page 184 and 185: XENIX Programming lex: Lexical Anal
- Page 186 and 187: XENIX Programming lex: Lexical Anal
- Page 188 and 189: XENIX Programming lex: Lexical Anal
- Page 190 and 191: XENIX Programming lex: Lexical Anal
- Page 192 and 193: XENIX Programm ing lex: Lexical Ana
- Page 194 and 195: XENIX Programming Specifying Source
- Page 196 and 197: XENIX Programming lex: Lexical Anal
- Page 198 and 199: XENIX Programming lex: Lexical Anal
- Page 200 and 201: XENIX Programming The definitions s
- Page 202 and 203: CHAPTER 10 yacc: COMPILER-COMPILER
- Page 204 and 205: XENIX Programming yacc: Compiler-Co
- Page 206 and 207: XENIX Programming yacc: Compiler-Co
- Page 208 and 209: XENIX Programming yacc: Compiler-Co
- Page 210 and 211: XENIX Programming yacc: Compiler-Co
- Page 212 and 213: XENIX Programming yacc: Compiler-Co
- Page 216 and 217: XENIX Programming yacc: Compiler-Co
- Page 218 and 219: XENIX Programming yacc: Compiler-Co
- Page 220 and 221: XENIX Programming yacc: Compiler-Co
- Page 222 and 223: XENIX Programming yacc: Compiler-Co
- Page 224 and 225: XENIX Programming yacc: Compiler-Co
- Page 226 and 227: XENIX Programming yacc: Compiler-Co
- Page 228 and 229: XENIX Programming yacc: Compiler-Co
- Page 230 and 231: XENIX Programming yacc: Compiler-Co
- Page 232 and 233: XENIX Programming yacc: Compiler-Co
- Page 234 and 235: XENIX Programming yacc: Compiler-Co
- Page 236 and 237: XENIX Programming %left %left %left
- Page 238 and 239: XENIX Programming I* lexical analys
- Page 240: XENIX Programming yacc: Compiler-Co
- Page 243 and 244: m4: Macro Processor XENIX Programmi
- Page 245 and 246: m4: Macro Processor XENIX Programmi
- Page 247 and 248: m4: Macro Processor XENIX Programm
- Page 249 and 250: m4: Macro Processor XENIX Programmi
- Page 251 and 252: m4: Macro Processor XENIX Programmi
- Page 253 and 254: C Language Portability XENIX Progra
- Page 255 and 256: C Language Portability XENIX Progra
- Page 257 and 258: C Language Portability XENIX Progra
- Page 259 and 260: C Language Portability XENIX Progra
- Page 261 and 262: C Language Portability XENIX Progra
- Page 263 and 264: C Language Portability XENIX Progra
<strong>XENIX</strong> Programming yacc: Compiler-Compiler<br />
Notice that, in addition to the actions for each state, there is a description of the<br />
parsing rules being processed in each state. The underscore character ( ) is used to<br />
indicate what has been seen and what is yet to come in each rule. Suppose the input is<br />
DING DONG DELL<br />
It is instructive to follow the steps of the parser while processing this input.<br />
Initially, the current state is state 0. The parser needs to refer to the input to decide<br />
between the actions available in state 0, so the first token, DING, is read, becoming the<br />
look-ahead token. The action in state 0 on DING is shift 3, so state 3 is pushed onto the<br />
stack, and the look-ahead token is cleared. State 3 becomes the current state. The<br />
next token, DONG, is read, becoming the look-ahead token. The action in state 3 on the<br />
token DONG is shift 6, so state 6 is pushed onto the stack, and the look-ahead is<br />
cleared. The stack now contains 0, 3, and 6. In state 6, without even consulting the<br />
look-ahead, the parser reduces by rule 2.<br />
sound : DING DONG<br />
This rule has two symbols on the right-hand side, so two states, 6 and 3, are popped off<br />
of the stack, uncovering state 0. Consulting the description of state 0, looking for a<br />
goto on sound<br />
sound goto 2<br />
is obtained; thus state 2 is pushed onto the stack, becoming the current state.<br />
In state 2, the next token, DELL, must be read. The action is shift 5, so state 5 is<br />
pushed onto the stack, which now has 0, 2, and 5 on it, and the look-ahead token is<br />
cleared. In state 5, the only action is to reduce by rule 3. This has one symbol on the<br />
right-hand side, so one state, 5, is popped off, and state 2 is uncovered. The goto in<br />
state 2 on place, the left side of rule 3, is state 4. Now the stack contains 0, 2, and 4. In<br />
state 4, the only action is to reduce by rule 1. There are two sy mbols on the right, so<br />
the top two states are popped off, uncovering state 0 again. In state 0, there is a goto<br />
on rhyme causing the parser to enter state 1. In state 1, the input is read; the<br />
endmarker is obtained, indicated by $end in the y.output file. The action in state 1<br />
when the endmarker is seen is to accept, successfully ending the parse.<br />
You should consider how the parser works when confronted with such incorrect strings<br />
as DING DONG DONG, DING DONG, DING DONG DELL DELL, e<strong>tc</strong>. A few minutes<br />
spent with this and other simple examples will probably be repaid when problems arise in<br />
more complicated contexts.<br />
10-13