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 The input being read may not conform to the specifications. These input errors are detected as early as is theoretically possible with a left-to-right scan; thus, not only is the chance of reading and computing with bad input data substantially reduced, but the bad data can usually be quickly found. Error handling, provided as part of the input specifications, permits the re-entry of bad data or the continuation of the input process after skipping over the bad data. In some cases, yacc fails to produce a parser when given a set of specifications. For example, the specifications may be self contradictory, or they may require a more powerful recognition mechanism than that available to yacc. The former cases represent design errors; the latter cases can often be corrected by making the lexical analyzer more powerful, or by rewriting some of the grammar rules. While yacc cannot handle all possible specifications, its power compares favorably with sim ilar systems; moreover, constructions difficult for yacc to handle are also frequently difficult for human beings to handle. Some users have reported that the discipline of formulating valid yacc specifications for their input revealed errors of conception or design early in the program development. The next several sections describe • The preparation of grammar rules • The preparation of the user-supplied actions associated with the grammar rules • The preparation of lexical analyzers • The operation of the parser • Various reasons why yacc may be unable to produce a parser from a specification, and what to do about it • A simple mechanism for handling operator precedences in arithmetic expressions • Error detection and recovery o The operating environment and special features of the parsers yacc produces • Suggestions that should improve the style and efficiency of the specifications 10-3
yacc: Compiler-Compiler XENIX Programming Specifications Names refer to either tokens or nonterminal sy mbols. yacc requires token names to be declared as such. In addition, for reasons discussed later, it is often desirable to include the lexical analyzer as part of the specification file. It may be useful to include other programs as well. Thus, every specification file consists of three sections: the declarations, (grammar) rules, and programs. The sections are separated by double percent {%%) marks. (The percent sign {%) is generally used in yacc specifications as an escape character.) In other words, a full specification file looks like this: declarations %% rules %% programs The declaration section may be empty. Moreover, if the programs section is omitted, the second %% mark may be omitted also; thus, the smallest legal yacc specification is %% rules Blanks, tabs, and newlines are ignored except that they may not appear in names or multicharacter reserved symbols. Comments may appear wherever a name is legal; they are enclosed in /* ... *I, as in C. The rules section is made up of one or more grammar rules. A grammar rule has the form A : BODY ; where A represents a nonterminal name, and BODY represents a sequence of zero or more names and literals. The colon and the semicolon are yacc punctuation. Names may be of arbitrary length and may be made up of letters, dot (.), the underscore ( ), and noninitial digits. Uppercase and lowercase letters are distinct. The names used in the body of a grammar rule may represent tokens or nonterminal symbols. A literal consists of a character enclosed in single quotation marks ('). As in C, the backslash {\) is an escape character within literals, and all the C escapes are recognized: '\n' = Newline '\r' '\ = Return " = Single quotation mark '\\' = Backslash '\t' = Tab '\b' = Backspace '\f' = Form feed '\xxx' A character value specified by the octal number xxx For a number of technical reasons, the ASCII NULL character {'\0' or 0) should never be used in gram mar rules. 10-4
- Page 153 and 154: as: A sse m bier XENIX Programming
- Page 156 and 157: CHAPTER 8 csh : C SHEll The C shell
- Page 158 and 159: XENIX Programming csh: C Shell Some
- Page 160 and 161: XENIX Programm ing *w 32 * q % !c -
- Page 162 and 163: XENIX Programming csh: C Shell the
- 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 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 214 and 215: 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
yacc: Compiler-Compiler <strong>XENIX</strong> Programming<br />
Specifications<br />
Names refer to either tokens or nonterminal sy mbols. yacc requires token names to be<br />
declared as such. In addition, for reasons discussed later, it is often desirable to include<br />
the lexical analyzer as part of the specification file. It may be useful to include other<br />
programs as well. Thus, every specification file consists of three sections: the<br />
declarations, (grammar) rules, and programs. The sections are separated by double<br />
percent {%%) marks. (The percent sign {%) is generally used in yacc specifications as an<br />
escape character.) In other words, a full specification file looks like this:<br />
declarations<br />
%%<br />
rules<br />
%%<br />
programs<br />
The declaration section may be empty. Moreover, if the programs section is omitted,<br />
the second %% mark may be omitted also; thus, the smallest legal yacc specification is<br />
%%<br />
rules<br />
Blanks, tabs, and newlines are ignored except that they may not appear in names or<br />
multicharacter reserved symbols. Comments may appear wherever a name is legal; they<br />
are enclosed in /* ... *I, as in C.<br />
The rules section is made up of one or more grammar rules. A grammar rule has the<br />
form<br />
A : BODY ;<br />
where A represents a nonterminal name, and BODY represents a sequence of zero or<br />
more names and literals. The colon and the semicolon are yacc punctuation.<br />
Names may be of arbitrary length and may be made up of letters, dot (.), the underscore<br />
( ), and noninitial digits. Uppercase and lowercase letters are distinct. The names used<br />
in the body of a grammar rule may represent tokens or nonterminal symbols.<br />
A literal consists of a character enclosed in single quotation marks ('). As in C, the<br />
backslash {\) is an escape character within literals, and all the C escapes are recognized:<br />
'\n' = Newline<br />
'\r'<br />
'\<br />
= Return<br />
"<br />
= Single quotation mark<br />
'\\' = Backslash<br />
'\t' = Tab<br />
'\b' = Backspace<br />
'\f' = Form feed<br />
'\xxx' A character value specified by the octal number xxx<br />
For a number of technical reasons, the ASCII NULL character {'\0' or 0) should never be<br />
used in gram mar rules.<br />
10-4