Mercurial > repo
comparison ply-3.8/doc/ply.html @ 7267:343ff337a19b
<ais523> ` tar -xf ply-3.8.tar.gz
| author | HackBot |
|---|---|
| date | Wed, 23 Mar 2016 02:40:16 +0000 |
| parents | |
| children |
comparison
equal
deleted
inserted
replaced
| 7266:61a39a120dee | 7267:343ff337a19b |
|---|---|
| 1 <html> | |
| 2 <head> | |
| 3 <title>PLY (Python Lex-Yacc)</title> | |
| 4 </head> | |
| 5 <body bgcolor="#ffffff"> | |
| 6 | |
| 7 <h1>PLY (Python Lex-Yacc)</h1> | |
| 8 | |
| 9 <b> | |
| 10 David M. Beazley <br> | |
| 11 dave@dabeaz.com<br> | |
| 12 </b> | |
| 13 | |
| 14 <p> | |
| 15 <b>PLY Version: 3.6</b> | |
| 16 <p> | |
| 17 | |
| 18 <!-- INDEX --> | |
| 19 <div class="sectiontoc"> | |
| 20 <ul> | |
| 21 <li><a href="#ply_nn1">Preface and Requirements</a> | |
| 22 <li><a href="#ply_nn1">Introduction</a> | |
| 23 <li><a href="#ply_nn2">PLY Overview</a> | |
| 24 <li><a href="#ply_nn3">Lex</a> | |
| 25 <ul> | |
| 26 <li><a href="#ply_nn4">Lex Example</a> | |
| 27 <li><a href="#ply_nn5">The tokens list</a> | |
| 28 <li><a href="#ply_nn6">Specification of tokens</a> | |
| 29 <li><a href="#ply_nn7">Token values</a> | |
| 30 <li><a href="#ply_nn8">Discarded tokens</a> | |
| 31 <li><a href="#ply_nn9">Line numbers and positional information</a> | |
| 32 <li><a href="#ply_nn10">Ignored characters</a> | |
| 33 <li><a href="#ply_nn11">Literal characters</a> | |
| 34 <li><a href="#ply_nn12">Error handling</a> | |
| 35 <li><a href="#ply_nn14">EOF Handling</a> | |
| 36 <li><a href="#ply_nn13">Building and using the lexer</a> | |
| 37 <li><a href="#ply_nn14">The @TOKEN decorator</a> | |
| 38 <li><a href="#ply_nn15">Optimized mode</a> | |
| 39 <li><a href="#ply_nn16">Debugging</a> | |
| 40 <li><a href="#ply_nn17">Alternative specification of lexers</a> | |
| 41 <li><a href="#ply_nn18">Maintaining state</a> | |
| 42 <li><a href="#ply_nn19">Lexer cloning</a> | |
| 43 <li><a href="#ply_nn20">Internal lexer state</a> | |
| 44 <li><a href="#ply_nn21">Conditional lexing and start conditions</a> | |
| 45 <li><a href="#ply_nn21">Miscellaneous Issues</a> | |
| 46 </ul> | |
| 47 <li><a href="#ply_nn22">Parsing basics</a> | |
| 48 <li><a href="#ply_nn23">Yacc</a> | |
| 49 <ul> | |
| 50 <li><a href="#ply_nn24">An example</a> | |
| 51 <li><a href="#ply_nn25">Combining Grammar Rule Functions</a> | |
| 52 <li><a href="#ply_nn26">Character Literals</a> | |
| 53 <li><a href="#ply_nn26">Empty Productions</a> | |
| 54 <li><a href="#ply_nn28">Changing the starting symbol</a> | |
| 55 <li><a href="#ply_nn27">Dealing With Ambiguous Grammars</a> | |
| 56 <li><a href="#ply_nn28">The parser.out file</a> | |
| 57 <li><a href="#ply_nn29">Syntax Error Handling</a> | |
| 58 <ul> | |
| 59 <li><a href="#ply_nn30">Recovery and resynchronization with error rules</a> | |
| 60 <li><a href="#ply_nn31">Panic mode recovery</a> | |
| 61 <li><a href="#ply_nn35">Signalling an error from a production</a> | |
| 62 <li><a href="#ply_nn38">When Do Syntax Errors Get Reported</a> | |
| 63 <li><a href="#ply_nn32">General comments on error handling</a> | |
| 64 </ul> | |
| 65 <li><a href="#ply_nn33">Line Number and Position Tracking</a> | |
| 66 <li><a href="#ply_nn34">AST Construction</a> | |
| 67 <li><a href="#ply_nn35">Embedded Actions</a> | |
| 68 <li><a href="#ply_nn36">Miscellaneous Yacc Notes</a> | |
| 69 </ul> | |
| 70 <li><a href="#ply_nn37">Multiple Parsers and Lexers</a> | |
| 71 <li><a href="#ply_nn38">Using Python's Optimized Mode</a> | |
| 72 <li><a href="#ply_nn44">Advanced Debugging</a> | |
| 73 <ul> | |
| 74 <li><a href="#ply_nn45">Debugging the lex() and yacc() commands</a> | |
| 75 <li><a href="#ply_nn46">Run-time Debugging</a> | |
| 76 </ul> | |
| 77 <li><a href="#ply_nn49">Packaging Advice</a> | |
| 78 <li><a href="#ply_nn39">Where to go from here?</a> | |
| 79 </ul> | |
| 80 </div> | |
| 81 <!-- INDEX --> | |
| 82 | |
| 83 | |
| 84 | |
| 85 | |
| 86 | |
| 87 <H2><a name="ply_nn1"></a>1. Preface and Requirements</H2> | |
| 88 | |
| 89 | |
| 90 <p> | |
| 91 This document provides an overview of lexing and parsing with PLY. | |
| 92 Given the intrinsic complexity of parsing, I would strongly advise | |
| 93 that you read (or at least skim) this entire document before jumping | |
| 94 into a big development project with PLY. | |
| 95 </p> | |
| 96 | |
| 97 <p> | |
| 98 PLY-3.5 is compatible with both Python 2 and Python 3. If you are using | |
| 99 Python 2, you have to use Python 2.6 or newer. | |
| 100 </p> | |
| 101 | |
| 102 <H2><a name="ply_nn1"></a>2. Introduction</H2> | |
| 103 | |
| 104 | |
| 105 PLY is a pure-Python implementation of the popular compiler | |
| 106 construction tools lex and yacc. The main goal of PLY is to stay | |
| 107 fairly faithful to the way in which traditional lex/yacc tools work. | |
| 108 This includes supporting LALR(1) parsing as well as providing | |
| 109 extensive input validation, error reporting, and diagnostics. Thus, | |
| 110 if you've used yacc in another programming language, it should be | |
| 111 relatively straightforward to use PLY. | |
| 112 | |
| 113 <p> | |
| 114 Early versions of PLY were developed to support an Introduction to | |
| 115 Compilers Course I taught in 2001 at the University of Chicago. | |
| 116 Since PLY was primarily developed as an instructional tool, you will | |
| 117 find it to be fairly picky about token and grammar rule | |
| 118 specification. In part, this | |
| 119 added formality is meant to catch common programming mistakes made by | |
| 120 novice users. However, advanced users will also find such features to | |
| 121 be useful when building complicated grammars for real programming | |
| 122 languages. It should also be noted that PLY does not provide much in | |
| 123 the way of bells and whistles (e.g., automatic construction of | |
| 124 abstract syntax trees, tree traversal, etc.). Nor would I consider it | |
| 125 to be a parsing framework. Instead, you will find a bare-bones, yet | |
| 126 fully capable lex/yacc implementation written entirely in Python. | |
| 127 | |
| 128 <p> | |
| 129 The rest of this document assumes that you are somewhat familiar with | |
| 130 parsing theory, syntax directed translation, and the use of compiler | |
| 131 construction tools such as lex and yacc in other programming | |
| 132 languages. If you are unfamiliar with these topics, you will probably | |
| 133 want to consult an introductory text such as "Compilers: Principles, | |
| 134 Techniques, and Tools", by Aho, Sethi, and Ullman. O'Reilly's "Lex | |
| 135 and Yacc" by John Levine may also be handy. In fact, the O'Reilly book can be | |
| 136 used as a reference for PLY as the concepts are virtually identical. | |
| 137 | |
| 138 <H2><a name="ply_nn2"></a>3. PLY Overview</H2> | |
| 139 | |
| 140 | |
| 141 <p> | |
| 142 PLY consists of two separate modules; <tt>lex.py</tt> and | |
| 143 <tt>yacc.py</tt>, both of which are found in a Python package | |
| 144 called <tt>ply</tt>. The <tt>lex.py</tt> module is used to break input text into a | |
| 145 collection of tokens specified by a collection of regular expression | |
| 146 rules. <tt>yacc.py</tt> is used to recognize language syntax that has | |
| 147 been specified in the form of a context free grammar. | |
| 148 </p> | |
| 149 | |
| 150 <p> | |
| 151 The two tools are meant to work together. Specifically, | |
| 152 <tt>lex.py</tt> provides an external interface in the form of a | |
| 153 <tt>token()</tt> function that returns the next valid token on the | |
| 154 input stream. <tt>yacc.py</tt> calls this repeatedly to retrieve | |
| 155 tokens and invoke grammar rules. The output of <tt>yacc.py</tt> is | |
| 156 often an Abstract Syntax Tree (AST). However, this is entirely up to | |
| 157 the user. If desired, <tt>yacc.py</tt> can also be used to implement | |
| 158 simple one-pass compilers. | |
| 159 | |
| 160 <p> | |
| 161 Like its Unix counterpart, <tt>yacc.py</tt> provides most of the | |
| 162 features you expect including extensive error checking, grammar | |
| 163 validation, support for empty productions, error tokens, and ambiguity | |
| 164 resolution via precedence rules. In fact, almost everything that is possible in traditional yacc | |
| 165 should be supported in PLY. | |
| 166 | |
| 167 <p> | |
| 168 The primary difference between | |
| 169 <tt>yacc.py</tt> and Unix <tt>yacc</tt> is that <tt>yacc.py</tt> | |
| 170 doesn't involve a separate code-generation process. | |
| 171 Instead, PLY relies on reflection (introspection) | |
| 172 to build its lexers and parsers. Unlike traditional lex/yacc which | |
| 173 require a special input file that is converted into a separate source | |
| 174 file, the specifications given to PLY <em>are</em> valid Python | |
| 175 programs. This means that there are no extra source files nor is | |
| 176 there a special compiler construction step (e.g., running yacc to | |
| 177 generate Python code for the compiler). Since the generation of the | |
| 178 parsing tables is relatively expensive, PLY caches the results and | |
| 179 saves them to a file. If no changes are detected in the input source, | |
| 180 the tables are read from the cache. Otherwise, they are regenerated. | |
| 181 | |
| 182 <H2><a name="ply_nn3"></a>4. Lex</H2> | |
| 183 | |
| 184 | |
| 185 <tt>lex.py</tt> is used to tokenize an input string. For example, suppose | |
| 186 you're writing a programming language and a user supplied the following input string: | |
| 187 | |
| 188 <blockquote> | |
| 189 <pre> | |
| 190 x = 3 + 42 * (s - t) | |
| 191 </pre> | |
| 192 </blockquote> | |
| 193 | |
| 194 A tokenizer splits the string into individual tokens | |
| 195 | |
| 196 <blockquote> | |
| 197 <pre> | |
| 198 'x','=', '3', '+', '42', '*', '(', 's', '-', 't', ')' | |
| 199 </pre> | |
| 200 </blockquote> | |
| 201 | |
| 202 Tokens are usually given names to indicate what they are. For example: | |
| 203 | |
| 204 <blockquote> | |
| 205 <pre> | |
| 206 'ID','EQUALS','NUMBER','PLUS','NUMBER','TIMES', | |
| 207 'LPAREN','ID','MINUS','ID','RPAREN' | |
| 208 </pre> | |
| 209 </blockquote> | |
| 210 | |
| 211 More specifically, the input is broken into pairs of token types and values. For example: | |
| 212 | |
| 213 <blockquote> | |
| 214 <pre> | |
| 215 ('ID','x'), ('EQUALS','='), ('NUMBER','3'), | |
| 216 ('PLUS','+'), ('NUMBER','42), ('TIMES','*'), | |
| 217 ('LPAREN','('), ('ID','s'), ('MINUS','-'), | |
| 218 ('ID','t'), ('RPAREN',')' | |
| 219 </pre> | |
| 220 </blockquote> | |
| 221 | |
| 222 The identification of tokens is typically done by writing a series of regular expression | |
| 223 rules. The next section shows how this is done using <tt>lex.py</tt>. | |
| 224 | |
| 225 <H3><a name="ply_nn4"></a>4.1 Lex Example</H3> | |
| 226 | |
| 227 | |
| 228 The following example shows how <tt>lex.py</tt> is used to write a simple tokenizer. | |
| 229 | |
| 230 <blockquote> | |
| 231 <pre> | |
| 232 # ------------------------------------------------------------ | |
| 233 # calclex.py | |
| 234 # | |
| 235 # tokenizer for a simple expression evaluator for | |
| 236 # numbers and +,-,*,/ | |
| 237 # ------------------------------------------------------------ | |
| 238 import ply.lex as lex | |
| 239 | |
| 240 # List of token names. This is always required | |
| 241 tokens = ( | |
| 242 'NUMBER', | |
| 243 'PLUS', | |
| 244 'MINUS', | |
| 245 'TIMES', | |
| 246 'DIVIDE', | |
| 247 'LPAREN', | |
| 248 'RPAREN', | |
| 249 ) | |
| 250 | |
| 251 # Regular expression rules for simple tokens | |
| 252 t_PLUS = r'\+' | |
| 253 t_MINUS = r'-' | |
| 254 t_TIMES = r'\*' | |
| 255 t_DIVIDE = r'/' | |
| 256 t_LPAREN = r'\(' | |
| 257 t_RPAREN = r'\)' | |
| 258 | |
| 259 # A regular expression rule with some action code | |
| 260 def t_NUMBER(t): | |
| 261 r'\d+' | |
| 262 t.value = int(t.value) | |
| 263 return t | |
| 264 | |
| 265 # Define a rule so we can track line numbers | |
| 266 def t_newline(t): | |
| 267 r'\n+' | |
| 268 t.lexer.lineno += len(t.value) | |
| 269 | |
| 270 # A string containing ignored characters (spaces and tabs) | |
| 271 t_ignore = ' \t' | |
| 272 | |
| 273 # Error handling rule | |
| 274 def t_error(t): | |
| 275 print("Illegal character '%s'" % t.value[0]) | |
| 276 t.lexer.skip(1) | |
| 277 | |
| 278 # Build the lexer | |
| 279 lexer = lex.lex() | |
| 280 | |
| 281 </pre> | |
| 282 </blockquote> | |
| 283 To use the lexer, you first need to feed it some input text using | |
| 284 its <tt>input()</tt> method. After that, repeated calls | |
| 285 to <tt>token()</tt> produce tokens. The following code shows how this | |
| 286 works: | |
| 287 | |
| 288 <blockquote> | |
| 289 <pre> | |
| 290 | |
| 291 # Test it out | |
| 292 data = ''' | |
| 293 3 + 4 * 10 | |
| 294 + -20 *2 | |
| 295 ''' | |
| 296 | |
| 297 # Give the lexer some input | |
| 298 lexer.input(data) | |
| 299 | |
| 300 # Tokenize | |
| 301 while True: | |
| 302 tok = lexer.token() | |
| 303 if not tok: | |
| 304 break # No more input | |
| 305 print(tok) | |
| 306 </pre> | |
| 307 </blockquote> | |
| 308 | |
| 309 When executed, the example will produce the following output: | |
| 310 | |
| 311 <blockquote> | |
| 312 <pre> | |
| 313 $ python example.py | |
| 314 LexToken(NUMBER,3,2,1) | |
| 315 LexToken(PLUS,'+',2,3) | |
| 316 LexToken(NUMBER,4,2,5) | |
| 317 LexToken(TIMES,'*',2,7) | |
| 318 LexToken(NUMBER,10,2,10) | |
| 319 LexToken(PLUS,'+',3,14) | |
| 320 LexToken(MINUS,'-',3,16) | |
| 321 LexToken(NUMBER,20,3,18) | |
| 322 LexToken(TIMES,'*',3,20) | |
| 323 LexToken(NUMBER,2,3,21) | |
| 324 </pre> | |
| 325 </blockquote> | |
| 326 | |
| 327 Lexers also support the iteration protocol. So, you can write the above loop as follows: | |
| 328 | |
| 329 <blockquote> | |
| 330 <pre> | |
| 331 for tok in lexer: | |
| 332 print(tok) | |
| 333 </pre> | |
| 334 </blockquote> | |
| 335 | |
| 336 The tokens returned by <tt>lexer.token()</tt> are instances | |
| 337 of <tt>LexToken</tt>. This object has | |
| 338 attributes <tt>tok.type</tt>, <tt>tok.value</tt>, | |
| 339 <tt>tok.lineno</tt>, and <tt>tok.lexpos</tt>. The following code shows an example of | |
| 340 accessing these attributes: | |
| 341 | |
| 342 <blockquote> | |
| 343 <pre> | |
| 344 # Tokenize | |
| 345 while True: | |
| 346 tok = lexer.token() | |
| 347 if not tok: | |
| 348 break # No more input | |
| 349 print(tok.type, tok.value, tok.lineno, tok.lexpos) | |
| 350 </pre> | |
| 351 </blockquote> | |
| 352 | |
| 353 The <tt>tok.type</tt> and <tt>tok.value</tt> attributes contain the | |
| 354 type and value of the token itself. | |
| 355 <tt>tok.line</tt> and <tt>tok.lexpos</tt> contain information about | |
| 356 the location of the token. <tt>tok.lexpos</tt> is the index of the | |
| 357 token relative to the start of the input text. | |
| 358 | |
| 359 <H3><a name="ply_nn5"></a>4.2 The tokens list</H3> | |
| 360 | |
| 361 | |
| 362 <p> | |
| 363 All lexers must provide a list <tt>tokens</tt> that defines all of the possible token | |
| 364 names that can be produced by the lexer. This list is always required | |
| 365 and is used to perform a variety of validation checks. The tokens list is also used by the | |
| 366 <tt>yacc.py</tt> module to identify terminals. | |
| 367 </p> | |
| 368 | |
| 369 <p> | |
| 370 In the example, the following code specified the token names: | |
| 371 | |
| 372 <blockquote> | |
| 373 <pre> | |
| 374 tokens = ( | |
| 375 'NUMBER', | |
| 376 'PLUS', | |
| 377 'MINUS', | |
| 378 'TIMES', | |
| 379 'DIVIDE', | |
| 380 'LPAREN', | |
| 381 'RPAREN', | |
| 382 ) | |
| 383 </pre> | |
| 384 </blockquote> | |
| 385 | |
| 386 <H3><a name="ply_nn6"></a>4.3 Specification of tokens</H3> | |
| 387 | |
| 388 | |
| 389 Each token is specified by writing a regular expression rule compatible with Python's <tt>re</tt> module. Each of these rules | |
| 390 are defined by making declarations with a special prefix <tt>t_</tt> to indicate that it | |
| 391 defines a token. For simple tokens, the regular expression can | |
| 392 be specified as strings such as this (note: Python raw strings are used since they are the | |
| 393 most convenient way to write regular expression strings): | |
| 394 | |
| 395 <blockquote> | |
| 396 <pre> | |
| 397 t_PLUS = r'\+' | |
| 398 </pre> | |
| 399 </blockquote> | |
| 400 | |
| 401 In this case, the name following the <tt>t_</tt> must exactly match one of the | |
| 402 names supplied in <tt>tokens</tt>. If some kind of action needs to be performed, | |
| 403 a token rule can be specified as a function. For example, this rule matches numbers and | |
| 404 converts the string into a Python integer. | |
| 405 | |
| 406 <blockquote> | |
| 407 <pre> | |
| 408 def t_NUMBER(t): | |
| 409 r'\d+' | |
| 410 t.value = int(t.value) | |
| 411 return t | |
| 412 </pre> | |
| 413 </blockquote> | |
| 414 | |
| 415 When a function is used, the regular expression rule is specified in the function documentation string. | |
| 416 The function always takes a single argument which is an instance of | |
| 417 <tt>LexToken</tt>. This object has attributes of <tt>t.type</tt> which is the token type (as a string), | |
| 418 <tt>t.value</tt> which is the lexeme (the actual text matched), <tt>t.lineno</tt> which is the current line number, and <tt>t.lexpos</tt> which | |
| 419 is the position of the token relative to the beginning of the input text. | |
| 420 By default, <tt>t.type</tt> is set to the name following the <tt>t_</tt> prefix. The action | |
| 421 function can modify the contents of the <tt>LexToken</tt> object as appropriate. However, | |
| 422 when it is done, the resulting token should be returned. If no value is returned by the action | |
| 423 function, the token is simply discarded and the next token read. | |
| 424 | |
| 425 <p> | |
| 426 Internally, <tt>lex.py</tt> uses the <tt>re</tt> module to do its pattern matching. Patterns are compiled | |
| 427 using the <tt>re.VERBOSE</tt> flag which can be used to help readability. However, be aware that unescaped | |
| 428 whitespace is ignored and comments are allowed in this mode. If your pattern involves whitespace, make sure you | |
| 429 use <tt>\s</tt>. If you need to match the <tt>#</tt> character, use <tt>[#]</tt>. | |
| 430 </p> | |
| 431 | |
| 432 <p> | |
| 433 When building the master regular expression, | |
| 434 rules are added in the following order: | |
| 435 </p> | |
| 436 | |
| 437 <p> | |
| 438 <ol> | |
| 439 <li>All tokens defined by functions are added in the same order as they appear in the lexer file. | |
| 440 <li>Tokens defined by strings are added next by sorting them in order of decreasing regular expression length (longer expressions | |
| 441 are added first). | |
| 442 </ol> | |
| 443 <p> | |
| 444 Without this ordering, it can be difficult to correctly match certain types of tokens. For example, if you | |
| 445 wanted to have separate tokens for "=" and "==", you need to make sure that "==" is checked first. By sorting regular | |
| 446 expressions in order of decreasing length, this problem is solved for rules defined as strings. For functions, | |
| 447 the order can be explicitly controlled since rules appearing first are checked first. | |
| 448 | |
| 449 <p> | |
| 450 To handle reserved words, you should write a single rule to match an | |
| 451 identifier and do a special name lookup in a function like this: | |
| 452 | |
| 453 <blockquote> | |
| 454 <pre> | |
| 455 reserved = { | |
| 456 'if' : 'IF', | |
| 457 'then' : 'THEN', | |
| 458 'else' : 'ELSE', | |
| 459 'while' : 'WHILE', | |
| 460 ... | |
| 461 } | |
| 462 | |
| 463 tokens = ['LPAREN','RPAREN',...,'ID'] + list(reserved.values()) | |
| 464 | |
| 465 def t_ID(t): | |
| 466 r'[a-zA-Z_][a-zA-Z_0-9]*' | |
| 467 t.type = reserved.get(t.value,'ID') # Check for reserved words | |
| 468 return t | |
| 469 </pre> | |
| 470 </blockquote> | |
| 471 | |
| 472 This approach greatly reduces the number of regular expression rules and is likely to make things a little faster. | |
| 473 | |
| 474 <p> | |
| 475 <b>Note:</b> You should avoid writing individual rules for reserved words. For example, if you write rules like this, | |
| 476 | |
| 477 <blockquote> | |
| 478 <pre> | |
| 479 t_FOR = r'for' | |
| 480 t_PRINT = r'print' | |
| 481 </pre> | |
| 482 </blockquote> | |
| 483 | |
| 484 those rules will be triggered for identifiers that include those words as a prefix such as "forget" or "printed". This is probably not | |
| 485 what you want. | |
| 486 | |
| 487 <H3><a name="ply_nn7"></a>4.4 Token values</H3> | |
| 488 | |
| 489 | |
| 490 When tokens are returned by lex, they have a value that is stored in the <tt>value</tt> attribute. Normally, the value is the text | |
| 491 that was matched. However, the value can be assigned to any Python object. For instance, when lexing identifiers, you may | |
| 492 want to return both the identifier name and information from some sort of symbol table. To do this, you might write a rule like this: | |
| 493 | |
| 494 <blockquote> | |
| 495 <pre> | |
| 496 def t_ID(t): | |
| 497 ... | |
| 498 # Look up symbol table information and return a tuple | |
| 499 t.value = (t.value, symbol_lookup(t.value)) | |
| 500 ... | |
| 501 return t | |
| 502 </pre> | |
| 503 </blockquote> | |
| 504 | |
| 505 It is important to note that storing data in other attribute names is <em>not</em> recommended. The <tt>yacc.py</tt> module only exposes the | |
| 506 contents of the <tt>value</tt> attribute. Thus, accessing other attributes may be unnecessarily awkward. If you | |
| 507 need to store multiple values on a token, assign a tuple, dictionary, or instance to <tt>value</tt>. | |
| 508 | |
| 509 <H3><a name="ply_nn8"></a>4.5 Discarded tokens</H3> | |
| 510 | |
| 511 | |
| 512 To discard a token, such as a comment, simply define a token rule that returns no value. For example: | |
| 513 | |
| 514 <blockquote> | |
| 515 <pre> | |
| 516 def t_COMMENT(t): | |
| 517 r'\#.*' | |
| 518 pass | |
| 519 # No return value. Token discarded | |
| 520 </pre> | |
| 521 </blockquote> | |
| 522 | |
| 523 Alternatively, you can include the prefix "ignore_" in the token declaration to force a token to be ignored. For example: | |
| 524 | |
| 525 <blockquote> | |
| 526 <pre> | |
| 527 t_ignore_COMMENT = r'\#.*' | |
| 528 </pre> | |
| 529 </blockquote> | |
| 530 | |
| 531 Be advised that if you are ignoring many different kinds of text, you may still want to use functions since these provide more precise | |
| 532 control over the order in which regular expressions are matched (i.e., functions are matched in order of specification whereas strings are | |
| 533 sorted by regular expression length). | |
| 534 | |
| 535 <H3><a name="ply_nn9"></a>4.6 Line numbers and positional information</H3> | |
| 536 | |
| 537 | |
| 538 <p>By default, <tt>lex.py</tt> knows nothing about line numbers. This is because <tt>lex.py</tt> doesn't know anything | |
| 539 about what constitutes a "line" of input (e.g., the newline character or even if the input is textual data). | |
| 540 To update this information, you need to write a special rule. In the example, the <tt>t_newline()</tt> rule shows how to do this. | |
| 541 | |
| 542 <blockquote> | |
| 543 <pre> | |
| 544 # Define a rule so we can track line numbers | |
| 545 def t_newline(t): | |
| 546 r'\n+' | |
| 547 t.lexer.lineno += len(t.value) | |
| 548 </pre> | |
| 549 </blockquote> | |
| 550 Within the rule, the <tt>lineno</tt> attribute of the underlying lexer <tt>t.lexer</tt> is updated. | |
| 551 After the line number is updated, the token is simply discarded since nothing is returned. | |
| 552 | |
| 553 <p> | |
| 554 <tt>lex.py</tt> does not perform and kind of automatic column tracking. However, it does record positional | |
| 555 information related to each token in the <tt>lexpos</tt> attribute. Using this, it is usually possible to compute | |
| 556 column information as a separate step. For instance, just count backwards until you reach a newline. | |
| 557 | |
| 558 <blockquote> | |
| 559 <pre> | |
| 560 # Compute column. | |
| 561 # input is the input text string | |
| 562 # token is a token instance | |
| 563 def find_column(input,token): | |
| 564 last_cr = input.rfind('\n',0,token.lexpos) | |
| 565 if last_cr < 0: | |
| 566 last_cr = 0 | |
| 567 column = (token.lexpos - last_cr) + 1 | |
| 568 return column | |
| 569 </pre> | |
| 570 </blockquote> | |
| 571 | |
| 572 Since column information is often only useful in the context of error handling, calculating the column | |
| 573 position can be performed when needed as opposed to doing it for each token. | |
| 574 | |
| 575 <H3><a name="ply_nn10"></a>4.7 Ignored characters</H3> | |
| 576 | |
| 577 | |
| 578 <p> | |
| 579 The special <tt>t_ignore</tt> rule is reserved by <tt>lex.py</tt> for characters | |
| 580 that should be completely ignored in the input stream. | |
| 581 Usually this is used to skip over whitespace and other non-essential characters. | |
| 582 Although it is possible to define a regular expression rule for whitespace in a manner | |
| 583 similar to <tt>t_newline()</tt>, the use of <tt>t_ignore</tt> provides substantially better | |
| 584 lexing performance because it is handled as a special case and is checked in a much | |
| 585 more efficient manner than the normal regular expression rules. | |
| 586 </p> | |
| 587 | |
| 588 <p> | |
| 589 The characters given in <tt>t_ignore</tt> are not ignored when such characters are part of | |
| 590 other regular expression patterns. For example, if you had a rule to capture quoted text, | |
| 591 that pattern can include the ignored characters (which will be captured in the normal way). The | |
| 592 main purpose of <tt>t_ignore</tt> is to ignore whitespace and other padding between the | |
| 593 tokens that you actually want to parse. | |
| 594 </p> | |
| 595 | |
| 596 <H3><a name="ply_nn11"></a>4.8 Literal characters</H3> | |
| 597 | |
| 598 | |
| 599 <p> | |
| 600 Literal characters can be specified by defining a variable <tt>literals</tt> in your lexing module. For example: | |
| 601 | |
| 602 <blockquote> | |
| 603 <pre> | |
| 604 literals = [ '+','-','*','/' ] | |
| 605 </pre> | |
| 606 </blockquote> | |
| 607 | |
| 608 or alternatively | |
| 609 | |
| 610 <blockquote> | |
| 611 <pre> | |
| 612 literals = "+-*/" | |
| 613 </pre> | |
| 614 </blockquote> | |
| 615 | |
| 616 A literal character is simply a single character that is returned "as is" when encountered by the lexer. Literals are checked | |
| 617 after all of the defined regular expression rules. Thus, if a rule starts with one of the literal characters, it will always | |
| 618 take precedence. | |
| 619 | |
| 620 <p> | |
| 621 When a literal token is returned, both its <tt>type</tt> and <tt>value</tt> attributes are set to the character itself. For example, <tt>'+'</tt>. | |
| 622 </p> | |
| 623 | |
| 624 <p> | |
| 625 It's possible to write token functions that perform additional actions | |
| 626 when literals are matched. However, you'll need to set the token type | |
| 627 appropriately. For example: | |
| 628 </p> | |
| 629 | |
| 630 <blockquote> | |
| 631 <pre> | |
| 632 literals = [ '{', '}' ] | |
| 633 | |
| 634 def t_lbrace(t): | |
| 635 r'\{' | |
| 636 t.type = '{' # Set token type to the expected literal | |
| 637 return t | |
| 638 | |
| 639 def t_rbrace(t): | |
| 640 r'\}' | |
| 641 t.type = '}' # Set token type to the expected literal | |
| 642 return t | |
| 643 </pre> | |
| 644 </blockquote> | |
| 645 | |
| 646 <H3><a name="ply_nn12"></a>4.9 Error handling</H3> | |
| 647 | |
| 648 | |
| 649 <p> | |
| 650 The <tt>t_error()</tt> | |
| 651 function is used to handle lexing errors that occur when illegal | |
| 652 characters are detected. In this case, the <tt>t.value</tt> attribute contains the | |
| 653 rest of the input string that has not been tokenized. In the example, the error function | |
| 654 was defined as follows: | |
| 655 | |
| 656 <blockquote> | |
| 657 <pre> | |
| 658 # Error handling rule | |
| 659 def t_error(t): | |
| 660 print("Illegal character '%s'" % t.value[0]) | |
| 661 t.lexer.skip(1) | |
| 662 </pre> | |
| 663 </blockquote> | |
| 664 | |
| 665 In this case, we simply print the offending character and skip ahead one character by calling <tt>t.lexer.skip(1)</tt>. | |
| 666 | |
| 667 <H3><a name="ply_nn14"></a>4.10 EOF Handling</H3> | |
| 668 | |
| 669 | |
| 670 <p> | |
| 671 The <tt>t_eof()</tt> function is used to handle an end-of-file (EOF) condition in the input. As input, it | |
| 672 receives a token type <tt>'eof'</tt> with the <tt>lineno</tt> and <tt>lexpos</tt> attributes set appropriately. | |
| 673 The main use of this function is provide more input to the lexer so that it can continue to parse. Here is an | |
| 674 example of how this works: | |
| 675 </p> | |
| 676 | |
| 677 <blockquote> | |
| 678 <pre> | |
| 679 # EOF handling rule | |
| 680 def t_eof(t): | |
| 681 # Get more input (Example) | |
| 682 more = raw_input('... ') | |
| 683 if more: | |
| 684 self.lexer.input(more) | |
| 685 return self.lexer.token() | |
| 686 return None | |
| 687 </pre> | |
| 688 </blockquote> | |
| 689 | |
| 690 <p> | |
| 691 The EOF function should return the next available token (by calling <tt>self.lexer.token())</tt> or <tt>None</tt> to | |
| 692 indicate no more data. Be aware that setting more input with the <tt>self.lexer.input()</tt> method does | |
| 693 NOT reset the lexer state or the <tt>lineno</tt> attribute used for position tracking. The <tt>lexpos</tt> | |
| 694 attribute is reset so be aware of that if you're using it in error reporting. | |
| 695 </p> | |
| 696 | |
| 697 <H3><a name="ply_nn13"></a>4.11 Building and using the lexer</H3> | |
| 698 | |
| 699 | |
| 700 <p> | |
| 701 To build the lexer, the function <tt>lex.lex()</tt> is used. For example:</p> | |
| 702 | |
| 703 <blockquote> | |
| 704 <pre> | |
| 705 lexer = lex.lex() | |
| 706 </pre> | |
| 707 </blockquote> | |
| 708 | |
| 709 <p>This function | |
| 710 uses Python reflection (or introspection) to read the regular expression rules | |
| 711 out of the calling context and build the lexer. Once the lexer has been built, two methods can | |
| 712 be used to control the lexer. | |
| 713 </p> | |
| 714 <ul> | |
| 715 <li><tt>lexer.input(data)</tt>. Reset the lexer and store a new input string. | |
| 716 <li><tt>lexer.token()</tt>. Return the next token. Returns a special <tt>LexToken</tt> instance on success or | |
| 717 None if the end of the input text has been reached. | |
| 718 </ul> | |
| 719 | |
| 720 <H3><a name="ply_nn14"></a>4.12 The @TOKEN decorator</H3> | |
| 721 | |
| 722 | |
| 723 In some applications, you may want to define build tokens from as a series of | |
| 724 more complex regular expression rules. For example: | |
| 725 | |
| 726 <blockquote> | |
| 727 <pre> | |
| 728 digit = r'([0-9])' | |
| 729 nondigit = r'([_A-Za-z])' | |
| 730 identifier = r'(' + nondigit + r'(' + digit + r'|' + nondigit + r')*)' | |
| 731 | |
| 732 def t_ID(t): | |
| 733 # want docstring to be identifier above. ????? | |
| 734 ... | |
| 735 </pre> | |
| 736 </blockquote> | |
| 737 | |
| 738 In this case, we want the regular expression rule for <tt>ID</tt> to be one of the variables above. However, there is no | |
| 739 way to directly specify this using a normal documentation string. To solve this problem, you can use the <tt>@TOKEN</tt> | |
| 740 decorator. For example: | |
| 741 | |
| 742 <blockquote> | |
| 743 <pre> | |
| 744 from ply.lex import TOKEN | |
| 745 | |
| 746 @TOKEN(identifier) | |
| 747 def t_ID(t): | |
| 748 ... | |
| 749 </pre> | |
| 750 </blockquote> | |
| 751 | |
| 752 <p> | |
| 753 This will attach <tt>identifier</tt> to the docstring for <tt>t_ID()</tt> allowing <tt>lex.py</tt> to work normally. | |
| 754 </p> | |
| 755 | |
| 756 <H3><a name="ply_nn15"></a>4.13 Optimized mode</H3> | |
| 757 | |
| 758 | |
| 759 For improved performance, it may be desirable to use Python's | |
| 760 optimized mode (e.g., running Python with the <tt>-O</tt> | |
| 761 option). However, doing so causes Python to ignore documentation | |
| 762 strings. This presents special problems for <tt>lex.py</tt>. To | |
| 763 handle this case, you can create your lexer using | |
| 764 the <tt>optimize</tt> option as follows: | |
| 765 | |
| 766 <blockquote> | |
| 767 <pre> | |
| 768 lexer = lex.lex(optimize=1) | |
| 769 </pre> | |
| 770 </blockquote> | |
| 771 | |
| 772 Next, run Python in its normal operating mode. When you do | |
| 773 this, <tt>lex.py</tt> will write a file called <tt>lextab.py</tt> in | |
| 774 the same directory as the module containing the lexer specification. | |
| 775 This file contains all of the regular | |
| 776 expression rules and tables used during lexing. On subsequent | |
| 777 executions, | |
| 778 <tt>lextab.py</tt> will simply be imported to build the lexer. This | |
| 779 approach substantially improves the startup time of the lexer and it | |
| 780 works in Python's optimized mode. | |
| 781 | |
| 782 <p> | |
| 783 To change the name of the lexer-generated module, use the <tt>lextab</tt> keyword argument. For example: | |
| 784 </p> | |
| 785 | |
| 786 <blockquote> | |
| 787 <pre> | |
| 788 lexer = lex.lex(optimize=1,lextab="footab") | |
| 789 </pre> | |
| 790 </blockquote> | |
| 791 | |
| 792 When running in optimized mode, it is important to note that lex disables most error checking. Thus, this is really only recommended | |
| 793 if you're sure everything is working correctly and you're ready to start releasing production code. | |
| 794 | |
| 795 <H3><a name="ply_nn16"></a>4.14 Debugging</H3> | |
| 796 | |
| 797 | |
| 798 For the purpose of debugging, you can run <tt>lex()</tt> in a debugging mode as follows: | |
| 799 | |
| 800 <blockquote> | |
| 801 <pre> | |
| 802 lexer = lex.lex(debug=1) | |
| 803 </pre> | |
| 804 </blockquote> | |
| 805 | |
| 806 <p> | |
| 807 This will produce various sorts of debugging information including all of the added rules, | |
| 808 the master regular expressions used by the lexer, and tokens generating during lexing. | |
| 809 </p> | |
| 810 | |
| 811 <p> | |
| 812 In addition, <tt>lex.py</tt> comes with a simple main function which | |
| 813 will either tokenize input read from standard input or from a file specified | |
| 814 on the command line. To use it, simply put this in your lexer: | |
| 815 </p> | |
| 816 | |
| 817 <blockquote> | |
| 818 <pre> | |
| 819 if __name__ == '__main__': | |
| 820 lex.runmain() | |
| 821 </pre> | |
| 822 </blockquote> | |
| 823 | |
| 824 Please refer to the "Debugging" section near the end for some more advanced details | |
| 825 of debugging. | |
| 826 | |
| 827 <H3><a name="ply_nn17"></a>4.15 Alternative specification of lexers</H3> | |
| 828 | |
| 829 | |
| 830 As shown in the example, lexers are specified all within one Python module. If you want to | |
| 831 put token rules in a different module from the one in which you invoke <tt>lex()</tt>, use the | |
| 832 <tt>module</tt> keyword argument. | |
| 833 | |
| 834 <p> | |
| 835 For example, you might have a dedicated module that just contains | |
| 836 the token rules: | |
| 837 | |
| 838 <blockquote> | |
| 839 <pre> | |
| 840 # module: tokrules.py | |
| 841 # This module just contains the lexing rules | |
| 842 | |
| 843 # List of token names. This is always required | |
| 844 tokens = ( | |
| 845 'NUMBER', | |
| 846 'PLUS', | |
| 847 'MINUS', | |
| 848 'TIMES', | |
| 849 'DIVIDE', | |
| 850 'LPAREN', | |
| 851 'RPAREN', | |
| 852 ) | |
| 853 | |
| 854 # Regular expression rules for simple tokens | |
| 855 t_PLUS = r'\+' | |
| 856 t_MINUS = r'-' | |
| 857 t_TIMES = r'\*' | |
| 858 t_DIVIDE = r'/' | |
| 859 t_LPAREN = r'\(' | |
| 860 t_RPAREN = r'\)' | |
| 861 | |
| 862 # A regular expression rule with some action code | |
| 863 def t_NUMBER(t): | |
| 864 r'\d+' | |
| 865 t.value = int(t.value) | |
| 866 return t | |
| 867 | |
| 868 # Define a rule so we can track line numbers | |
| 869 def t_newline(t): | |
| 870 r'\n+' | |
| 871 t.lexer.lineno += len(t.value) | |
| 872 | |
| 873 # A string containing ignored characters (spaces and tabs) | |
| 874 t_ignore = ' \t' | |
| 875 | |
| 876 # Error handling rule | |
| 877 def t_error(t): | |
| 878 print("Illegal character '%s'" % t.value[0]) | |
| 879 t.lexer.skip(1) | |
| 880 </pre> | |
| 881 </blockquote> | |
| 882 | |
| 883 Now, if you wanted to build a tokenizer from these rules from within a different module, you would do the following (shown for Python interactive mode): | |
| 884 | |
| 885 <blockquote> | |
| 886 <pre> | |
| 887 >>> import tokrules | |
| 888 >>> <b>lexer = lex.lex(module=tokrules)</b> | |
| 889 >>> lexer.input("3 + 4") | |
| 890 >>> lexer.token() | |
| 891 LexToken(NUMBER,3,1,1,0) | |
| 892 >>> lexer.token() | |
| 893 LexToken(PLUS,'+',1,2) | |
| 894 >>> lexer.token() | |
| 895 LexToken(NUMBER,4,1,4) | |
| 896 >>> lexer.token() | |
| 897 None | |
| 898 >>> | |
| 899 </pre> | |
| 900 </blockquote> | |
| 901 | |
| 902 The <tt>module</tt> option can also be used to define lexers from instances of a class. For example: | |
| 903 | |
| 904 <blockquote> | |
| 905 <pre> | |
| 906 import ply.lex as lex | |
| 907 | |
| 908 class MyLexer(object): | |
| 909 # List of token names. This is always required | |
| 910 tokens = ( | |
| 911 'NUMBER', | |
| 912 'PLUS', | |
| 913 'MINUS', | |
| 914 'TIMES', | |
| 915 'DIVIDE', | |
| 916 'LPAREN', | |
| 917 'RPAREN', | |
| 918 ) | |
| 919 | |
| 920 # Regular expression rules for simple tokens | |
| 921 t_PLUS = r'\+' | |
| 922 t_MINUS = r'-' | |
| 923 t_TIMES = r'\*' | |
| 924 t_DIVIDE = r'/' | |
| 925 t_LPAREN = r'\(' | |
| 926 t_RPAREN = r'\)' | |
| 927 | |
| 928 # A regular expression rule with some action code | |
| 929 # Note addition of self parameter since we're in a class | |
| 930 def t_NUMBER(self,t): | |
| 931 r'\d+' | |
| 932 t.value = int(t.value) | |
| 933 return t | |
| 934 | |
| 935 # Define a rule so we can track line numbers | |
| 936 def t_newline(self,t): | |
| 937 r'\n+' | |
| 938 t.lexer.lineno += len(t.value) | |
| 939 | |
| 940 # A string containing ignored characters (spaces and tabs) | |
| 941 t_ignore = ' \t' | |
| 942 | |
| 943 # Error handling rule | |
| 944 def t_error(self,t): | |
| 945 print("Illegal character '%s'" % t.value[0]) | |
| 946 t.lexer.skip(1) | |
| 947 | |
| 948 <b># Build the lexer | |
| 949 def build(self,**kwargs): | |
| 950 self.lexer = lex.lex(module=self, **kwargs)</b> | |
| 951 | |
| 952 # Test it output | |
| 953 def test(self,data): | |
| 954 self.lexer.input(data) | |
| 955 while True: | |
| 956 tok = self.lexer.token() | |
| 957 if not tok: | |
| 958 break | |
| 959 print(tok) | |
| 960 | |
| 961 # Build the lexer and try it out | |
| 962 m = MyLexer() | |
| 963 m.build() # Build the lexer | |
| 964 m.test("3 + 4") # Test it | |
| 965 </pre> | |
| 966 </blockquote> | |
| 967 | |
| 968 | |
| 969 When building a lexer from class, <em>you should construct the lexer from | |
| 970 an instance of the class</em>, not the class object itself. This is because | |
| 971 PLY only works properly if the lexer actions are defined by bound-methods. | |
| 972 | |
| 973 <p> | |
| 974 When using the <tt>module</tt> option to <tt>lex()</tt>, PLY collects symbols | |
| 975 from the underlying object using the <tt>dir()</tt> function. There is no | |
| 976 direct access to the <tt>__dict__</tt> attribute of the object supplied as a | |
| 977 module value. </p> | |
| 978 | |
| 979 <P> | |
| 980 Finally, if you want to keep things nicely encapsulated, but don't want to use a | |
| 981 full-fledged class definition, lexers can be defined using closures. For example: | |
| 982 | |
| 983 <blockquote> | |
| 984 <pre> | |
| 985 import ply.lex as lex | |
| 986 | |
| 987 # List of token names. This is always required | |
| 988 tokens = ( | |
| 989 'NUMBER', | |
| 990 'PLUS', | |
| 991 'MINUS', | |
| 992 'TIMES', | |
| 993 'DIVIDE', | |
| 994 'LPAREN', | |
| 995 'RPAREN', | |
| 996 ) | |
| 997 | |
| 998 def MyLexer(): | |
| 999 # Regular expression rules for simple tokens | |
| 1000 t_PLUS = r'\+' | |
| 1001 t_MINUS = r'-' | |
| 1002 t_TIMES = r'\*' | |
| 1003 t_DIVIDE = r'/' | |
| 1004 t_LPAREN = r'\(' | |
| 1005 t_RPAREN = r'\)' | |
| 1006 | |
| 1007 # A regular expression rule with some action code | |
| 1008 def t_NUMBER(t): | |
| 1009 r'\d+' | |
| 1010 t.value = int(t.value) | |
| 1011 return t | |
| 1012 | |
| 1013 # Define a rule so we can track line numbers | |
| 1014 def t_newline(t): | |
| 1015 r'\n+' | |
| 1016 t.lexer.lineno += len(t.value) | |
| 1017 | |
| 1018 # A string containing ignored characters (spaces and tabs) | |
| 1019 t_ignore = ' \t' | |
| 1020 | |
| 1021 # Error handling rule | |
| 1022 def t_error(t): | |
| 1023 print("Illegal character '%s'" % t.value[0]) | |
| 1024 t.lexer.skip(1) | |
| 1025 | |
| 1026 # Build the lexer from my environment and return it | |
| 1027 return lex.lex() | |
| 1028 </pre> | |
| 1029 </blockquote> | |
| 1030 | |
| 1031 <p> | |
| 1032 <b>Important note:</b> If you are defining a lexer using a class or closure, be aware that PLY still requires you to only | |
| 1033 define a single lexer per module (source file). There are extensive validation/error checking parts of the PLY that | |
| 1034 may falsely report error messages if you don't follow this rule. | |
| 1035 </p> | |
| 1036 | |
| 1037 <H3><a name="ply_nn18"></a>4.16 Maintaining state</H3> | |
| 1038 | |
| 1039 | |
| 1040 In your lexer, you may want to maintain a variety of state | |
| 1041 information. This might include mode settings, symbol tables, and | |
| 1042 other details. As an example, suppose that you wanted to keep | |
| 1043 track of how many NUMBER tokens had been encountered. | |
| 1044 | |
| 1045 <p> | |
| 1046 One way to do this is to keep a set of global variables in the module | |
| 1047 where you created the lexer. For example: | |
| 1048 | |
| 1049 <blockquote> | |
| 1050 <pre> | |
| 1051 num_count = 0 | |
| 1052 def t_NUMBER(t): | |
| 1053 r'\d+' | |
| 1054 global num_count | |
| 1055 num_count += 1 | |
| 1056 t.value = int(t.value) | |
| 1057 return t | |
| 1058 </pre> | |
| 1059 </blockquote> | |
| 1060 | |
| 1061 If you don't like the use of a global variable, another place to store | |
| 1062 information is inside the Lexer object created by <tt>lex()</tt>. | |
| 1063 To this, you can use the <tt>lexer</tt> attribute of tokens passed to | |
| 1064 the various rules. For example: | |
| 1065 | |
| 1066 <blockquote> | |
| 1067 <pre> | |
| 1068 def t_NUMBER(t): | |
| 1069 r'\d+' | |
| 1070 t.lexer.num_count += 1 # Note use of lexer attribute | |
| 1071 t.value = int(t.value) | |
| 1072 return t | |
| 1073 | |
| 1074 lexer = lex.lex() | |
| 1075 lexer.num_count = 0 # Set the initial count | |
| 1076 </pre> | |
| 1077 </blockquote> | |
| 1078 | |
| 1079 This latter approach has the advantage of being simple and working | |
| 1080 correctly in applications where multiple instantiations of a given | |
| 1081 lexer exist in the same application. However, this might also feel | |
| 1082 like a gross violation of encapsulation to OO purists. | |
| 1083 Just to put your mind at some ease, all | |
| 1084 internal attributes of the lexer (with the exception of <tt>lineno</tt>) have names that are prefixed | |
| 1085 by <tt>lex</tt> (e.g., <tt>lexdata</tt>,<tt>lexpos</tt>, etc.). Thus, | |
| 1086 it is perfectly safe to store attributes in the lexer that | |
| 1087 don't have names starting with that prefix or a name that conflicts with one of the | |
| 1088 predefined methods (e.g., <tt>input()</tt>, <tt>token()</tt>, etc.). | |
| 1089 | |
| 1090 <p> | |
| 1091 If you don't like assigning values on the lexer object, you can define your lexer as a class as | |
| 1092 shown in the previous section: | |
| 1093 | |
| 1094 <blockquote> | |
| 1095 <pre> | |
| 1096 class MyLexer: | |
| 1097 ... | |
| 1098 def t_NUMBER(self,t): | |
| 1099 r'\d+' | |
| 1100 self.num_count += 1 | |
| 1101 t.value = int(t.value) | |
| 1102 return t | |
| 1103 | |
| 1104 def build(self, **kwargs): | |
| 1105 self.lexer = lex.lex(object=self,**kwargs) | |
| 1106 | |
| 1107 def __init__(self): | |
| 1108 self.num_count = 0 | |
| 1109 </pre> | |
| 1110 </blockquote> | |
| 1111 | |
| 1112 The class approach may be the easiest to manage if your application is | |
| 1113 going to be creating multiple instances of the same lexer and you need | |
| 1114 to manage a lot of state. | |
| 1115 | |
| 1116 <p> | |
| 1117 State can also be managed through closures. For example, in Python 3: | |
| 1118 | |
| 1119 <blockquote> | |
| 1120 <pre> | |
| 1121 def MyLexer(): | |
| 1122 num_count = 0 | |
| 1123 ... | |
| 1124 def t_NUMBER(t): | |
| 1125 r'\d+' | |
| 1126 nonlocal num_count | |
| 1127 num_count += 1 | |
| 1128 t.value = int(t.value) | |
| 1129 return t | |
| 1130 ... | |
| 1131 </pre> | |
| 1132 </blockquote> | |
| 1133 | |
| 1134 <H3><a name="ply_nn19"></a>4.17 Lexer cloning</H3> | |
| 1135 | |
| 1136 | |
| 1137 <p> | |
| 1138 If necessary, a lexer object can be duplicated by invoking its <tt>clone()</tt> method. For example: | |
| 1139 | |
| 1140 <blockquote> | |
| 1141 <pre> | |
| 1142 lexer = lex.lex() | |
| 1143 ... | |
| 1144 newlexer = lexer.clone() | |
| 1145 </pre> | |
| 1146 </blockquote> | |
| 1147 | |
| 1148 When a lexer is cloned, the copy is exactly identical to the original lexer | |
| 1149 including any input text and internal state. However, the clone allows a | |
| 1150 different set of input text to be supplied which may be processed separately. | |
| 1151 This may be useful in situations when you are writing a parser/compiler that | |
| 1152 involves recursive or reentrant processing. For instance, if you | |
| 1153 needed to scan ahead in the input for some reason, you could create a | |
| 1154 clone and use it to look ahead. Or, if you were implementing some kind of preprocessor, | |
| 1155 cloned lexers could be used to handle different input files. | |
| 1156 | |
| 1157 <p> | |
| 1158 Creating a clone is different than calling <tt>lex.lex()</tt> in that | |
| 1159 PLY doesn't regenerate any of the internal tables or regular expressions. | |
| 1160 | |
| 1161 <p> | |
| 1162 Special considerations need to be made when cloning lexers that also | |
| 1163 maintain their own internal state using classes or closures. Namely, | |
| 1164 you need to be aware that the newly created lexers will share all of | |
| 1165 this state with the original lexer. For example, if you defined a | |
| 1166 lexer as a class and did this: | |
| 1167 | |
| 1168 <blockquote> | |
| 1169 <pre> | |
| 1170 m = MyLexer() | |
| 1171 a = lex.lex(object=m) # Create a lexer | |
| 1172 | |
| 1173 b = a.clone() # Clone the lexer | |
| 1174 </pre> | |
| 1175 </blockquote> | |
| 1176 | |
| 1177 Then both <tt>a</tt> and <tt>b</tt> are going to be bound to the same | |
| 1178 object <tt>m</tt> and any changes to <tt>m</tt> will be reflected in both lexers. It's | |
| 1179 important to emphasize that <tt>clone()</tt> is only meant to create a new lexer | |
| 1180 that reuses the regular expressions and environment of another lexer. If you | |
| 1181 need to make a totally new copy of a lexer, then call <tt>lex()</tt> again. | |
| 1182 | |
| 1183 <H3><a name="ply_nn20"></a>4.18 Internal lexer state</H3> | |
| 1184 | |
| 1185 | |
| 1186 A Lexer object <tt>lexer</tt> has a number of internal attributes that may be useful in certain | |
| 1187 situations. | |
| 1188 | |
| 1189 <p> | |
| 1190 <tt>lexer.lexpos</tt> | |
| 1191 <blockquote> | |
| 1192 This attribute is an integer that contains the current position within the input text. If you modify | |
| 1193 the value, it will change the result of the next call to <tt>token()</tt>. Within token rule functions, this points | |
| 1194 to the first character <em>after</em> the matched text. If the value is modified within a rule, the next returned token will be | |
| 1195 matched at the new position. | |
| 1196 </blockquote> | |
| 1197 | |
| 1198 <p> | |
| 1199 <tt>lexer.lineno</tt> | |
| 1200 <blockquote> | |
| 1201 The current value of the line number attribute stored in the lexer. PLY only specifies that the attribute | |
| 1202 exists---it never sets, updates, or performs any processing with it. If you want to track line numbers, | |
| 1203 you will need to add code yourself (see the section on line numbers and positional information). | |
| 1204 </blockquote> | |
| 1205 | |
| 1206 <p> | |
| 1207 <tt>lexer.lexdata</tt> | |
| 1208 <blockquote> | |
| 1209 The current input text stored in the lexer. This is the string passed with the <tt>input()</tt> method. It | |
| 1210 would probably be a bad idea to modify this unless you really know what you're doing. | |
| 1211 </blockquote> | |
| 1212 | |
| 1213 <P> | |
| 1214 <tt>lexer.lexmatch</tt> | |
| 1215 <blockquote> | |
| 1216 This is the raw <tt>Match</tt> object returned by the Python <tt>re.match()</tt> function (used internally by PLY) for the | |
| 1217 current token. If you have written a regular expression that contains named groups, you can use this to retrieve those values. | |
| 1218 Note: This attribute is only updated when tokens are defined and processed by functions. | |
| 1219 </blockquote> | |
| 1220 | |
| 1221 <H3><a name="ply_nn21"></a>4.19 Conditional lexing and start conditions</H3> | |
| 1222 | |
| 1223 | |
| 1224 In advanced parsing applications, it may be useful to have different | |
| 1225 lexing states. For instance, you may want the occurrence of a certain | |
| 1226 token or syntactic construct to trigger a different kind of lexing. | |
| 1227 PLY supports a feature that allows the underlying lexer to be put into | |
| 1228 a series of different states. Each state can have its own tokens, | |
| 1229 lexing rules, and so forth. The implementation is based largely on | |
| 1230 the "start condition" feature of GNU flex. Details of this can be found | |
| 1231 at <a | |
| 1232 href="http://flex.sourceforge.net/manual/Start-Conditions.html">http://flex.sourceforge.net/manual/Start-Conditions.html</a>. | |
| 1233 | |
| 1234 <p> | |
| 1235 To define a new lexing state, it must first be declared. This is done by including a "states" declaration in your | |
| 1236 lex file. For example: | |
| 1237 | |
| 1238 <blockquote> | |
| 1239 <pre> | |
| 1240 states = ( | |
| 1241 ('foo','exclusive'), | |
| 1242 ('bar','inclusive'), | |
| 1243 ) | |
| 1244 </pre> | |
| 1245 </blockquote> | |
| 1246 | |
| 1247 This declaration declares two states, <tt>'foo'</tt> | |
| 1248 and <tt>'bar'</tt>. States may be of two types; <tt>'exclusive'</tt> | |
| 1249 and <tt>'inclusive'</tt>. An exclusive state completely overrides the | |
| 1250 default behavior of the lexer. That is, lex will only return tokens | |
| 1251 and apply rules defined specifically for that state. An inclusive | |
| 1252 state adds additional tokens and rules to the default set of rules. | |
| 1253 Thus, lex will return both the tokens defined by default in addition | |
| 1254 to those defined for the inclusive state. | |
| 1255 | |
| 1256 <p> | |
| 1257 Once a state has been declared, tokens and rules are declared by including the | |
| 1258 state name in token/rule declaration. For example: | |
| 1259 | |
| 1260 <blockquote> | |
| 1261 <pre> | |
| 1262 t_foo_NUMBER = r'\d+' # Token 'NUMBER' in state 'foo' | |
| 1263 t_bar_ID = r'[a-zA-Z_][a-zA-Z0-9_]*' # Token 'ID' in state 'bar' | |
| 1264 | |
| 1265 def t_foo_newline(t): | |
| 1266 r'\n' | |
| 1267 t.lexer.lineno += 1 | |
| 1268 </pre> | |
| 1269 </blockquote> | |
| 1270 | |
| 1271 A token can be declared in multiple states by including multiple state names in the declaration. For example: | |
| 1272 | |
| 1273 <blockquote> | |
| 1274 <pre> | |
| 1275 t_foo_bar_NUMBER = r'\d+' # Defines token 'NUMBER' in both state 'foo' and 'bar' | |
| 1276 </pre> | |
| 1277 </blockquote> | |
| 1278 | |
| 1279 Alternative, a token can be declared in all states using the 'ANY' in the name. | |
| 1280 | |
| 1281 <blockquote> | |
| 1282 <pre> | |
| 1283 t_ANY_NUMBER = r'\d+' # Defines a token 'NUMBER' in all states | |
| 1284 </pre> | |
| 1285 </blockquote> | |
| 1286 | |
| 1287 If no state name is supplied, as is normally the case, the token is associated with a special state <tt>'INITIAL'</tt>. For example, | |
| 1288 these two declarations are identical: | |
| 1289 | |
| 1290 <blockquote> | |
| 1291 <pre> | |
| 1292 t_NUMBER = r'\d+' | |
| 1293 t_INITIAL_NUMBER = r'\d+' | |
| 1294 </pre> | |
| 1295 </blockquote> | |
| 1296 | |
| 1297 <p> | |
| 1298 States are also associated with the special <tt>t_ignore</tt>, <tt>t_error()</tt>, and <tt>t_eof()</tt> declarations. For example, if a state treats | |
| 1299 these differently, you can declare:</p> | |
| 1300 | |
| 1301 <blockquote> | |
| 1302 <pre> | |
| 1303 t_foo_ignore = " \t\n" # Ignored characters for state 'foo' | |
| 1304 | |
| 1305 def t_bar_error(t): # Special error handler for state 'bar' | |
| 1306 pass | |
| 1307 </pre> | |
| 1308 </blockquote> | |
| 1309 | |
| 1310 By default, lexing operates in the <tt>'INITIAL'</tt> state. This state includes all of the normally defined tokens. | |
| 1311 For users who aren't using different states, this fact is completely transparent. If, during lexing or parsing, you want to change | |
| 1312 the lexing state, use the <tt>begin()</tt> method. For example: | |
| 1313 | |
| 1314 <blockquote> | |
| 1315 <pre> | |
| 1316 def t_begin_foo(t): | |
| 1317 r'start_foo' | |
| 1318 t.lexer.begin('foo') # Starts 'foo' state | |
| 1319 </pre> | |
| 1320 </blockquote> | |
| 1321 | |
| 1322 To get out of a state, you use <tt>begin()</tt> to switch back to the initial state. For example: | |
| 1323 | |
| 1324 <blockquote> | |
| 1325 <pre> | |
| 1326 def t_foo_end(t): | |
| 1327 r'end_foo' | |
| 1328 t.lexer.begin('INITIAL') # Back to the initial state | |
| 1329 </pre> | |
| 1330 </blockquote> | |
| 1331 | |
| 1332 The management of states can also be done with a stack. For example: | |
| 1333 | |
| 1334 <blockquote> | |
| 1335 <pre> | |
| 1336 def t_begin_foo(t): | |
| 1337 r'start_foo' | |
| 1338 t.lexer.push_state('foo') # Starts 'foo' state | |
| 1339 | |
| 1340 def t_foo_end(t): | |
| 1341 r'end_foo' | |
| 1342 t.lexer.pop_state() # Back to the previous state | |
| 1343 </pre> | |
| 1344 </blockquote> | |
| 1345 | |
| 1346 <p> | |
| 1347 The use of a stack would be useful in situations where there are many ways of entering a new lexing state and you merely want to go back | |
| 1348 to the previous state afterwards. | |
| 1349 | |
| 1350 <P> | |
| 1351 An example might help clarify. Suppose you were writing a parser and you wanted to grab sections of arbitrary C code enclosed by | |
| 1352 curly braces. That is, whenever you encounter a starting brace '{', you want to read all of the enclosed code up to the ending brace '}' | |
| 1353 and return it as a string. Doing this with a normal regular expression rule is nearly (if not actually) impossible. This is because braces can | |
| 1354 be nested and can be included in comments and strings. Thus, simply matching up to the first matching '}' character isn't good enough. Here is how | |
| 1355 you might use lexer states to do this: | |
| 1356 | |
| 1357 <blockquote> | |
| 1358 <pre> | |
| 1359 # Declare the state | |
| 1360 states = ( | |
| 1361 ('ccode','exclusive'), | |
| 1362 ) | |
| 1363 | |
| 1364 # Match the first {. Enter ccode state. | |
| 1365 def t_ccode(t): | |
| 1366 r'\{' | |
| 1367 t.lexer.code_start = t.lexer.lexpos # Record the starting position | |
| 1368 t.lexer.level = 1 # Initial brace level | |
| 1369 t.lexer.begin('ccode') # Enter 'ccode' state | |
| 1370 | |
| 1371 # Rules for the ccode state | |
| 1372 def t_ccode_lbrace(t): | |
| 1373 r'\{' | |
| 1374 t.lexer.level +=1 | |
| 1375 | |
| 1376 def t_ccode_rbrace(t): | |
| 1377 r'\}' | |
| 1378 t.lexer.level -=1 | |
| 1379 | |
| 1380 # If closing brace, return the code fragment | |
| 1381 if t.lexer.level == 0: | |
| 1382 t.value = t.lexer.lexdata[t.lexer.code_start:t.lexer.lexpos+1] | |
| 1383 t.type = "CCODE" | |
| 1384 t.lexer.lineno += t.value.count('\n') | |
| 1385 t.lexer.begin('INITIAL') | |
| 1386 return t | |
| 1387 | |
| 1388 # C or C++ comment (ignore) | |
| 1389 def t_ccode_comment(t): | |
| 1390 r'(/\*(.|\n)*?\*/)|(//.*)' | |
| 1391 pass | |
| 1392 | |
| 1393 # C string | |
| 1394 def t_ccode_string(t): | |
| 1395 r'\"([^\\\n]|(\\.))*?\"' | |
| 1396 | |
| 1397 # C character literal | |
| 1398 def t_ccode_char(t): | |
| 1399 r'\'([^\\\n]|(\\.))*?\'' | |
| 1400 | |
| 1401 # Any sequence of non-whitespace characters (not braces, strings) | |
| 1402 def t_ccode_nonspace(t): | |
| 1403 r'[^\s\{\}\'\"]+' | |
| 1404 | |
| 1405 # Ignored characters (whitespace) | |
| 1406 t_ccode_ignore = " \t\n" | |
| 1407 | |
| 1408 # For bad characters, we just skip over it | |
| 1409 def t_ccode_error(t): | |
| 1410 t.lexer.skip(1) | |
| 1411 </pre> | |
| 1412 </blockquote> | |
| 1413 | |
| 1414 In this example, the occurrence of the first '{' causes the lexer to record the starting position and enter a new state <tt>'ccode'</tt>. A collection of rules then match | |
| 1415 various parts of the input that follow (comments, strings, etc.). All of these rules merely discard the token (by not returning a value). | |
| 1416 However, if the closing right brace is encountered, the rule <tt>t_ccode_rbrace</tt> collects all of the code (using the earlier recorded starting | |
| 1417 position), stores it, and returns a token 'CCODE' containing all of that text. When returning the token, the lexing state is restored back to its | |
| 1418 initial state. | |
| 1419 | |
| 1420 <H3><a name="ply_nn21"></a>4.20 Miscellaneous Issues</H3> | |
| 1421 | |
| 1422 | |
| 1423 <P> | |
| 1424 <li>The lexer requires input to be supplied as a single input string. Since most machines have more than enough memory, this | |
| 1425 rarely presents a performance concern. However, it means that the lexer currently can't be used with streaming data | |
| 1426 such as open files or sockets. This limitation is primarily a side-effect of using the <tt>re</tt> module. You might be | |
| 1427 able to work around this by implementing an appropriate <tt>def t_eof()</tt> end-of-file handling rule. The main complication | |
| 1428 here is that you'll probably need to ensure that data is fed to the lexer in a way so that it doesn't split in in the middle | |
| 1429 of a token.</p> | |
| 1430 | |
| 1431 <p> | |
| 1432 <li>The lexer should work properly with both Unicode strings given as token and pattern matching rules as | |
| 1433 well as for input text. | |
| 1434 | |
| 1435 <p> | |
| 1436 <li>If you need to supply optional flags to the re.compile() function, use the reflags option to lex. For example: | |
| 1437 | |
| 1438 <blockquote> | |
| 1439 <pre> | |
| 1440 lex.lex(reflags=re.UNICODE) | |
| 1441 </pre> | |
| 1442 </blockquote> | |
| 1443 | |
| 1444 <p> | |
| 1445 <li>Since the lexer is written entirely in Python, its performance is | |
| 1446 largely determined by that of the Python <tt>re</tt> module. Although | |
| 1447 the lexer has been written to be as efficient as possible, it's not | |
| 1448 blazingly fast when used on very large input files. If | |
| 1449 performance is concern, you might consider upgrading to the most | |
| 1450 recent version of Python, creating a hand-written lexer, or offloading | |
| 1451 the lexer into a C extension module. | |
| 1452 | |
| 1453 <p> | |
| 1454 If you are going to create a hand-written lexer and you plan to use it with <tt>yacc.py</tt>, | |
| 1455 it only needs to conform to the following requirements: | |
| 1456 | |
| 1457 <ul> | |
| 1458 <li>It must provide a <tt>token()</tt> method that returns the next token or <tt>None</tt> if no more | |
| 1459 tokens are available. | |
| 1460 <li>The <tt>token()</tt> method must return an object <tt>tok</tt> that has <tt>type</tt> and <tt>value</tt> attributes. If | |
| 1461 line number tracking is being used, then the token should also define a <tt>lineno</tt> attribute. | |
| 1462 </ul> | |
| 1463 | |
| 1464 <H2><a name="ply_nn22"></a>5. Parsing basics</H2> | |
| 1465 | |
| 1466 | |
| 1467 <tt>yacc.py</tt> is used to parse language syntax. Before showing an | |
| 1468 example, there are a few important bits of background that must be | |
| 1469 mentioned. First, <em>syntax</em> is usually specified in terms of a BNF grammar. | |
| 1470 For example, if you wanted to parse | |
| 1471 simple arithmetic expressions, you might first write an unambiguous | |
| 1472 grammar specification like this: | |
| 1473 | |
| 1474 <blockquote> | |
| 1475 <pre> | |
| 1476 expression : expression + term | |
| 1477 | expression - term | |
| 1478 | term | |
| 1479 | |
| 1480 term : term * factor | |
| 1481 | term / factor | |
| 1482 | factor | |
| 1483 | |
| 1484 factor : NUMBER | |
| 1485 | ( expression ) | |
| 1486 </pre> | |
| 1487 </blockquote> | |
| 1488 | |
| 1489 In the grammar, symbols such as <tt>NUMBER</tt>, <tt>+</tt>, <tt>-</tt>, <tt>*</tt>, and <tt>/</tt> are known | |
| 1490 as <em>terminals</em> and correspond to raw input tokens. Identifiers such as <tt>term</tt> and <tt>factor</tt> refer to | |
| 1491 grammar rules comprised of a collection of terminals and other rules. These identifiers are known as <em>non-terminals</em>. | |
| 1492 <P> | |
| 1493 | |
| 1494 The semantic behavior of a language is often specified using a | |
| 1495 technique known as syntax directed translation. In syntax directed | |
| 1496 translation, attributes are attached to each symbol in a given grammar | |
| 1497 rule along with an action. Whenever a particular grammar rule is | |
| 1498 recognized, the action describes what to do. For example, given the | |
| 1499 expression grammar above, you might write the specification for a | |
| 1500 simple calculator like this: | |
| 1501 | |
| 1502 <blockquote> | |
| 1503 <pre> | |
| 1504 Grammar Action | |
| 1505 -------------------------------- -------------------------------------------- | |
| 1506 expression0 : expression1 + term expression0.val = expression1.val + term.val | |
| 1507 | expression1 - term expression0.val = expression1.val - term.val | |
| 1508 | term expression0.val = term.val | |
| 1509 | |
| 1510 term0 : term1 * factor term0.val = term1.val * factor.val | |
| 1511 | term1 / factor term0.val = term1.val / factor.val | |
| 1512 | factor term0.val = factor.val | |
| 1513 | |
| 1514 factor : NUMBER factor.val = int(NUMBER.lexval) | |
| 1515 | ( expression ) factor.val = expression.val | |
| 1516 </pre> | |
| 1517 </blockquote> | |
| 1518 | |
| 1519 A good way to think about syntax directed translation is to | |
| 1520 view each symbol in the grammar as a kind of object. Associated | |
| 1521 with each symbol is a value representing its "state" (for example, the | |
| 1522 <tt>val</tt> attribute above). Semantic | |
| 1523 actions are then expressed as a collection of functions or methods | |
| 1524 that operate on the symbols and associated values. | |
| 1525 | |
| 1526 <p> | |
| 1527 Yacc uses a parsing technique known as LR-parsing or shift-reduce parsing. LR parsing is a | |
| 1528 bottom up technique that tries to recognize the right-hand-side of various grammar rules. | |
| 1529 Whenever a valid right-hand-side is found in the input, the appropriate action code is triggered and the | |
| 1530 grammar symbols are replaced by the grammar symbol on the left-hand-side. | |
| 1531 | |
| 1532 <p> | |
| 1533 LR parsing is commonly implemented by shifting grammar symbols onto a | |
| 1534 stack and looking at the stack and the next input token for patterns that | |
| 1535 match one of the grammar rules. | |
| 1536 The details of the algorithm can be found in a compiler textbook, but the | |
| 1537 following example illustrates the steps that are performed if you | |
| 1538 wanted to parse the expression | |
| 1539 <tt>3 + 5 * (10 - 20)</tt> using the grammar defined above. In the example, | |
| 1540 the special symbol <tt>$</tt> represents the end of input. | |
| 1541 | |
| 1542 | |
| 1543 <blockquote> | |
| 1544 <pre> | |
| 1545 Step Symbol Stack Input Tokens Action | |
| 1546 ---- --------------------- --------------------- ------------------------------- | |
| 1547 1 3 + 5 * ( 10 - 20 )$ Shift 3 | |
| 1548 2 3 + 5 * ( 10 - 20 )$ Reduce factor : NUMBER | |
| 1549 3 factor + 5 * ( 10 - 20 )$ Reduce term : factor | |
| 1550 4 term + 5 * ( 10 - 20 )$ Reduce expr : term | |
| 1551 5 expr + 5 * ( 10 - 20 )$ Shift + | |
| 1552 6 expr + 5 * ( 10 - 20 )$ Shift 5 | |
| 1553 7 expr + 5 * ( 10 - 20 )$ Reduce factor : NUMBER | |
| 1554 8 expr + factor * ( 10 - 20 )$ Reduce term : factor | |
| 1555 9 expr + term * ( 10 - 20 )$ Shift * | |
| 1556 10 expr + term * ( 10 - 20 )$ Shift ( | |
| 1557 11 expr + term * ( 10 - 20 )$ Shift 10 | |
| 1558 12 expr + term * ( 10 - 20 )$ Reduce factor : NUMBER | |
| 1559 13 expr + term * ( factor - 20 )$ Reduce term : factor | |
| 1560 14 expr + term * ( term - 20 )$ Reduce expr : term | |
| 1561 15 expr + term * ( expr - 20 )$ Shift - | |
| 1562 16 expr + term * ( expr - 20 )$ Shift 20 | |
| 1563 17 expr + term * ( expr - 20 )$ Reduce factor : NUMBER | |
| 1564 18 expr + term * ( expr - factor )$ Reduce term : factor | |
| 1565 19 expr + term * ( expr - term )$ Reduce expr : expr - term | |
| 1566 20 expr + term * ( expr )$ Shift ) | |
| 1567 21 expr + term * ( expr ) $ Reduce factor : (expr) | |
| 1568 22 expr + term * factor $ Reduce term : term * factor | |
| 1569 23 expr + term $ Reduce expr : expr + term | |
| 1570 24 expr $ Reduce expr | |
| 1571 25 $ Success! | |
| 1572 </pre> | |
| 1573 </blockquote> | |
| 1574 | |
| 1575 When parsing the expression, an underlying state machine and the | |
| 1576 current input token determine what happens next. If the next token | |
| 1577 looks like part of a valid grammar rule (based on other items on the | |
| 1578 stack), it is generally shifted onto the stack. If the top of the | |
| 1579 stack contains a valid right-hand-side of a grammar rule, it is | |
| 1580 usually "reduced" and the symbols replaced with the symbol on the | |
| 1581 left-hand-side. When this reduction occurs, the appropriate action is | |
| 1582 triggered (if defined). If the input token can't be shifted and the | |
| 1583 top of stack doesn't match any grammar rules, a syntax error has | |
| 1584 occurred and the parser must take some kind of recovery step (or bail | |
| 1585 out). A parse is only successful if the parser reaches a state where | |
| 1586 the symbol stack is empty and there are no more input tokens. | |
| 1587 | |
| 1588 <p> | |
| 1589 It is important to note that the underlying implementation is built | |
| 1590 around a large finite-state machine that is encoded in a collection of | |
| 1591 tables. The construction of these tables is non-trivial and | |
| 1592 beyond the scope of this discussion. However, subtle details of this | |
| 1593 process explain why, in the example above, the parser chooses to shift | |
| 1594 a token onto the stack in step 9 rather than reducing the | |
| 1595 rule <tt>expr : expr + term</tt>. | |
| 1596 | |
| 1597 <H2><a name="ply_nn23"></a>6. Yacc</H2> | |
| 1598 | |
| 1599 | |
| 1600 The <tt>ply.yacc</tt> module implements the parsing component of PLY. | |
| 1601 The name "yacc" stands for "Yet Another Compiler Compiler" and is | |
| 1602 borrowed from the Unix tool of the same name. | |
| 1603 | |
| 1604 <H3><a name="ply_nn24"></a>6.1 An example</H3> | |
| 1605 | |
| 1606 | |
| 1607 Suppose you wanted to make a grammar for simple arithmetic expressions as previously described. Here is | |
| 1608 how you would do it with <tt>yacc.py</tt>: | |
| 1609 | |
| 1610 <blockquote> | |
| 1611 <pre> | |
| 1612 # Yacc example | |
| 1613 | |
| 1614 import ply.yacc as yacc | |
| 1615 | |
| 1616 # Get the token map from the lexer. This is required. | |
| 1617 from calclex import tokens | |
| 1618 | |
| 1619 def p_expression_plus(p): | |
| 1620 'expression : expression PLUS term' | |
| 1621 p[0] = p[1] + p[3] | |
| 1622 | |
| 1623 def p_expression_minus(p): | |
| 1624 'expression : expression MINUS term' | |
| 1625 p[0] = p[1] - p[3] | |
| 1626 | |
| 1627 def p_expression_term(p): | |
| 1628 'expression : term' | |
| 1629 p[0] = p[1] | |
| 1630 | |
| 1631 def p_term_times(p): | |
| 1632 'term : term TIMES factor' | |
| 1633 p[0] = p[1] * p[3] | |
| 1634 | |
| 1635 def p_term_div(p): | |
| 1636 'term : term DIVIDE factor' | |
| 1637 p[0] = p[1] / p[3] | |
| 1638 | |
| 1639 def p_term_factor(p): | |
| 1640 'term : factor' | |
| 1641 p[0] = p[1] | |
| 1642 | |
| 1643 def p_factor_num(p): | |
| 1644 'factor : NUMBER' | |
| 1645 p[0] = p[1] | |
| 1646 | |
| 1647 def p_factor_expr(p): | |
| 1648 'factor : LPAREN expression RPAREN' | |
| 1649 p[0] = p[2] | |
| 1650 | |
| 1651 # Error rule for syntax errors | |
| 1652 def p_error(p): | |
| 1653 print("Syntax error in input!") | |
| 1654 | |
| 1655 # Build the parser | |
| 1656 parser = yacc.yacc() | |
| 1657 | |
| 1658 while True: | |
| 1659 try: | |
| 1660 s = raw_input('calc > ') | |
| 1661 except EOFError: | |
| 1662 break | |
| 1663 if not s: continue | |
| 1664 result = parser.parse(s) | |
| 1665 print(result) | |
| 1666 </pre> | |
| 1667 </blockquote> | |
| 1668 | |
| 1669 In this example, each grammar rule is defined by a Python function | |
| 1670 where the docstring to that function contains the appropriate | |
| 1671 context-free grammar specification. The statements that make up the | |
| 1672 function body implement the semantic actions of the rule. Each function | |
| 1673 accepts a single argument <tt>p</tt> that is a sequence containing the | |
| 1674 values of each grammar symbol in the corresponding rule. The values | |
| 1675 of <tt>p[i]</tt> are mapped to grammar symbols as shown here: | |
| 1676 | |
| 1677 <blockquote> | |
| 1678 <pre> | |
| 1679 def p_expression_plus(p): | |
| 1680 'expression : expression PLUS term' | |
| 1681 # ^ ^ ^ ^ | |
| 1682 # p[0] p[1] p[2] p[3] | |
| 1683 | |
| 1684 p[0] = p[1] + p[3] | |
| 1685 </pre> | |
| 1686 </blockquote> | |
| 1687 | |
| 1688 <p> | |
| 1689 For tokens, the "value" of the corresponding <tt>p[i]</tt> is the | |
| 1690 <em>same</em> as the <tt>p.value</tt> attribute assigned in the lexer | |
| 1691 module. For non-terminals, the value is determined by whatever is | |
| 1692 placed in <tt>p[0]</tt> when rules are reduced. This value can be | |
| 1693 anything at all. However, it probably most common for the value to be | |
| 1694 a simple Python type, a tuple, or an instance. In this example, we | |
| 1695 are relying on the fact that the <tt>NUMBER</tt> token stores an | |
| 1696 integer value in its value field. All of the other rules simply | |
| 1697 perform various types of integer operations and propagate the result. | |
| 1698 </p> | |
| 1699 | |
| 1700 <p> | |
| 1701 Note: The use of negative indices have a special meaning in | |
| 1702 yacc---specially <tt>p[-1]</tt> does not have the same value | |
| 1703 as <tt>p[3]</tt> in this example. Please see the section on "Embedded | |
| 1704 Actions" for further details. | |
| 1705 </p> | |
| 1706 | |
| 1707 <p> | |
| 1708 The first rule defined in the yacc specification determines the | |
| 1709 starting grammar symbol (in this case, a rule for <tt>expression</tt> | |
| 1710 appears first). Whenever the starting rule is reduced by the parser | |
| 1711 and no more input is available, parsing stops and the final value is | |
| 1712 returned (this value will be whatever the top-most rule placed | |
| 1713 in <tt>p[0]</tt>). Note: an alternative starting symbol can be | |
| 1714 specified using the <tt>start</tt> keyword argument to | |
| 1715 <tt>yacc()</tt>. | |
| 1716 | |
| 1717 <p>The <tt>p_error(p)</tt> rule is defined to catch syntax errors. | |
| 1718 See the error handling section below for more detail. | |
| 1719 | |
| 1720 <p> | |
| 1721 To build the parser, call the <tt>yacc.yacc()</tt> function. This | |
| 1722 function looks at the module and attempts to construct all of the LR | |
| 1723 parsing tables for the grammar you have specified. The first | |
| 1724 time <tt>yacc.yacc()</tt> is invoked, you will get a message such as | |
| 1725 this: | |
| 1726 | |
| 1727 <blockquote> | |
| 1728 <pre> | |
| 1729 $ python calcparse.py | |
| 1730 Generating LALR tables | |
| 1731 calc > | |
| 1732 </pre> | |
| 1733 </blockquote> | |
| 1734 | |
| 1735 <p> | |
| 1736 Since table construction is relatively expensive (especially for large | |
| 1737 grammars), the resulting parsing table is written to | |
| 1738 a file called <tt>parsetab.py</tt>. In addition, a | |
| 1739 debugging file called <tt>parser.out</tt> is created. On subsequent | |
| 1740 executions, <tt>yacc</tt> will reload the table from | |
| 1741 <tt>parsetab.py</tt> unless it has detected a change in the underlying | |
| 1742 grammar (in which case the tables and <tt>parsetab.py</tt> file are | |
| 1743 regenerated). Both of these files are written to the same directory | |
| 1744 as the module in which the parser is specified. | |
| 1745 The name of the <tt>parsetab</tt> module can be changed using the | |
| 1746 <tt>tabmodule</tt> keyword argument to <tt>yacc()</tt>. For example: | |
| 1747 </p> | |
| 1748 | |
| 1749 <blockquote> | |
| 1750 <pre> | |
| 1751 parser = yacc.yacc(tabmodule='fooparsetab') | |
| 1752 </pre> | |
| 1753 </blockquote> | |
| 1754 | |
| 1755 <p> | |
| 1756 If any errors are detected in your grammar specification, <tt>yacc.py</tt> will produce | |
| 1757 diagnostic messages and possibly raise an exception. Some of the errors that can be detected include: | |
| 1758 | |
| 1759 <ul> | |
| 1760 <li>Duplicated function names (if more than one rule function have the same name in the grammar file). | |
| 1761 <li>Shift/reduce and reduce/reduce conflicts generated by ambiguous grammars. | |
| 1762 <li>Badly specified grammar rules. | |
| 1763 <li>Infinite recursion (rules that can never terminate). | |
| 1764 <li>Unused rules and tokens | |
| 1765 <li>Undefined rules and tokens | |
| 1766 </ul> | |
| 1767 | |
| 1768 The next few sections discuss grammar specification in more detail. | |
| 1769 | |
| 1770 <p> | |
| 1771 The final part of the example shows how to actually run the parser | |
| 1772 created by | |
| 1773 <tt>yacc()</tt>. To run the parser, you simply have to call | |
| 1774 the <tt>parse()</tt> with a string of input text. This will run all | |
| 1775 of the grammar rules and return the result of the entire parse. This | |
| 1776 result return is the value assigned to <tt>p[0]</tt> in the starting | |
| 1777 grammar rule. | |
| 1778 | |
| 1779 <H3><a name="ply_nn25"></a>6.2 Combining Grammar Rule Functions</H3> | |
| 1780 | |
| 1781 | |
| 1782 When grammar rules are similar, they can be combined into a single function. | |
| 1783 For example, consider the two rules in our earlier example: | |
| 1784 | |
| 1785 <blockquote> | |
| 1786 <pre> | |
| 1787 def p_expression_plus(p): | |
| 1788 'expression : expression PLUS term' | |
| 1789 p[0] = p[1] + p[3] | |
| 1790 | |
| 1791 def p_expression_minus(t): | |
| 1792 'expression : expression MINUS term' | |
| 1793 p[0] = p[1] - p[3] | |
| 1794 </pre> | |
| 1795 </blockquote> | |
| 1796 | |
| 1797 Instead of writing two functions, you might write a single function like this: | |
| 1798 | |
| 1799 <blockquote> | |
| 1800 <pre> | |
| 1801 def p_expression(p): | |
| 1802 '''expression : expression PLUS term | |
| 1803 | expression MINUS term''' | |
| 1804 if p[2] == '+': | |
| 1805 p[0] = p[1] + p[3] | |
| 1806 elif p[2] == '-': | |
| 1807 p[0] = p[1] - p[3] | |
| 1808 </pre> | |
| 1809 </blockquote> | |
| 1810 | |
| 1811 In general, the doc string for any given function can contain multiple grammar rules. So, it would | |
| 1812 have also been legal (although possibly confusing) to write this: | |
| 1813 | |
| 1814 <blockquote> | |
| 1815 <pre> | |
| 1816 def p_binary_operators(p): | |
| 1817 '''expression : expression PLUS term | |
| 1818 | expression MINUS term | |
| 1819 term : term TIMES factor | |
| 1820 | term DIVIDE factor''' | |
| 1821 if p[2] == '+': | |
| 1822 p[0] = p[1] + p[3] | |
| 1823 elif p[2] == '-': | |
| 1824 p[0] = p[1] - p[3] | |
| 1825 elif p[2] == '*': | |
| 1826 p[0] = p[1] * p[3] | |
| 1827 elif p[2] == '/': | |
| 1828 p[0] = p[1] / p[3] | |
| 1829 </pre> | |
| 1830 </blockquote> | |
| 1831 | |
| 1832 When combining grammar rules into a single function, it is usually a good idea for all of the rules to have | |
| 1833 a similar structure (e.g., the same number of terms). Otherwise, the corresponding action code may be more | |
| 1834 complicated than necessary. However, it is possible to handle simple cases using len(). For example: | |
| 1835 | |
| 1836 <blockquote> | |
| 1837 <pre> | |
| 1838 def p_expressions(p): | |
| 1839 '''expression : expression MINUS expression | |
| 1840 | MINUS expression''' | |
| 1841 if (len(p) == 4): | |
| 1842 p[0] = p[1] - p[3] | |
| 1843 elif (len(p) == 3): | |
| 1844 p[0] = -p[2] | |
| 1845 </pre> | |
| 1846 </blockquote> | |
| 1847 | |
| 1848 If parsing performance is a concern, you should resist the urge to put | |
| 1849 too much conditional processing into a single grammar rule as shown in | |
| 1850 these examples. When you add checks to see which grammar rule is | |
| 1851 being handled, you are actually duplicating the work that the parser | |
| 1852 has already performed (i.e., the parser already knows exactly what rule it | |
| 1853 matched). You can eliminate this overhead by using a | |
| 1854 separate <tt>p_rule()</tt> function for each grammar rule. | |
| 1855 | |
| 1856 <H3><a name="ply_nn26"></a>6.3 Character Literals</H3> | |
| 1857 | |
| 1858 | |
| 1859 If desired, a grammar may contain tokens defined as single character literals. For example: | |
| 1860 | |
| 1861 <blockquote> | |
| 1862 <pre> | |
| 1863 def p_binary_operators(p): | |
| 1864 '''expression : expression '+' term | |
| 1865 | expression '-' term | |
| 1866 term : term '*' factor | |
| 1867 | term '/' factor''' | |
| 1868 if p[2] == '+': | |
| 1869 p[0] = p[1] + p[3] | |
| 1870 elif p[2] == '-': | |
| 1871 p[0] = p[1] - p[3] | |
| 1872 elif p[2] == '*': | |
| 1873 p[0] = p[1] * p[3] | |
| 1874 elif p[2] == '/': | |
| 1875 p[0] = p[1] / p[3] | |
| 1876 </pre> | |
| 1877 </blockquote> | |
| 1878 | |
| 1879 A character literal must be enclosed in quotes such as <tt>'+'</tt>. In addition, if literals are used, they must be declared in the | |
| 1880 corresponding <tt>lex</tt> file through the use of a special <tt>literals</tt> declaration. | |
| 1881 | |
| 1882 <blockquote> | |
| 1883 <pre> | |
| 1884 # Literals. Should be placed in module given to lex() | |
| 1885 literals = ['+','-','*','/' ] | |
| 1886 </pre> | |
| 1887 </blockquote> | |
| 1888 | |
| 1889 <b>Character literals are limited to a single character</b>. Thus, it is not legal to specify literals such as <tt>'<='</tt> or <tt>'=='</tt>. For this, use | |
| 1890 the normal lexing rules (e.g., define a rule such as <tt>t_EQ = r'=='</tt>). | |
| 1891 | |
| 1892 <H3><a name="ply_nn26"></a>6.4 Empty Productions</H3> | |
| 1893 | |
| 1894 | |
| 1895 <tt>yacc.py</tt> can handle empty productions by defining a rule like this: | |
| 1896 | |
| 1897 <blockquote> | |
| 1898 <pre> | |
| 1899 def p_empty(p): | |
| 1900 'empty :' | |
| 1901 pass | |
| 1902 </pre> | |
| 1903 </blockquote> | |
| 1904 | |
| 1905 Now to use the empty production, simply use 'empty' as a symbol. For example: | |
| 1906 | |
| 1907 <blockquote> | |
| 1908 <pre> | |
| 1909 def p_optitem(p): | |
| 1910 'optitem : item' | |
| 1911 ' | empty' | |
| 1912 ... | |
| 1913 </pre> | |
| 1914 </blockquote> | |
| 1915 | |
| 1916 Note: You can write empty rules anywhere by simply specifying an empty | |
| 1917 right hand side. However, I personally find that writing an "empty" | |
| 1918 rule and using "empty" to denote an empty production is easier to read | |
| 1919 and more clearly states your intentions. | |
| 1920 | |
| 1921 <H3><a name="ply_nn28"></a>6.5 Changing the starting symbol</H3> | |
| 1922 | |
| 1923 | |
| 1924 Normally, the first rule found in a yacc specification defines the starting grammar rule (top level rule). To change this, simply | |
| 1925 supply a <tt>start</tt> specifier in your file. For example: | |
| 1926 | |
| 1927 <blockquote> | |
| 1928 <pre> | |
| 1929 start = 'foo' | |
| 1930 | |
| 1931 def p_bar(p): | |
| 1932 'bar : A B' | |
| 1933 | |
| 1934 # This is the starting rule due to the start specifier above | |
| 1935 def p_foo(p): | |
| 1936 'foo : bar X' | |
| 1937 ... | |
| 1938 </pre> | |
| 1939 </blockquote> | |
| 1940 | |
| 1941 The use of a <tt>start</tt> specifier may be useful during debugging | |
| 1942 since you can use it to have yacc build a subset of a larger grammar. | |
| 1943 For this purpose, it is also possible to specify a starting symbol as | |
| 1944 an argument to <tt>yacc()</tt>. For example: | |
| 1945 | |
| 1946 <blockquote> | |
| 1947 <pre> | |
| 1948 parser = yacc.yacc(start='foo') | |
| 1949 </pre> | |
| 1950 </blockquote> | |
| 1951 | |
| 1952 <H3><a name="ply_nn27"></a>6.6 Dealing With Ambiguous Grammars</H3> | |
| 1953 | |
| 1954 | |
| 1955 The expression grammar given in the earlier example has been written | |
| 1956 in a special format to eliminate ambiguity. However, in many | |
| 1957 situations, it is extremely difficult or awkward to write grammars in | |
| 1958 this format. A much more natural way to express the grammar is in a | |
| 1959 more compact form like this: | |
| 1960 | |
| 1961 <blockquote> | |
| 1962 <pre> | |
| 1963 expression : expression PLUS expression | |
| 1964 | expression MINUS expression | |
| 1965 | expression TIMES expression | |
| 1966 | expression DIVIDE expression | |
| 1967 | LPAREN expression RPAREN | |
| 1968 | NUMBER | |
| 1969 </pre> | |
| 1970 </blockquote> | |
| 1971 | |
| 1972 Unfortunately, this grammar specification is ambiguous. For example, | |
| 1973 if you are parsing the string "3 * 4 + 5", there is no way to tell how | |
| 1974 the operators are supposed to be grouped. For example, does the | |
| 1975 expression mean "(3 * 4) + 5" or is it "3 * (4+5)"? | |
| 1976 | |
| 1977 <p> | |
| 1978 When an ambiguous grammar is given to <tt>yacc.py</tt> it will print | |
| 1979 messages about "shift/reduce conflicts" or "reduce/reduce conflicts". | |
| 1980 A shift/reduce conflict is caused when the parser generator can't | |
| 1981 decide whether or not to reduce a rule or shift a symbol on the | |
| 1982 parsing stack. For example, consider the string "3 * 4 + 5" and the | |
| 1983 internal parsing stack: | |
| 1984 | |
| 1985 <blockquote> | |
| 1986 <pre> | |
| 1987 Step Symbol Stack Input Tokens Action | |
| 1988 ---- --------------------- --------------------- ------------------------------- | |
| 1989 1 $ 3 * 4 + 5$ Shift 3 | |
| 1990 2 $ 3 * 4 + 5$ Reduce : expression : NUMBER | |
| 1991 3 $ expr * 4 + 5$ Shift * | |
| 1992 4 $ expr * 4 + 5$ Shift 4 | |
| 1993 5 $ expr * 4 + 5$ Reduce: expression : NUMBER | |
| 1994 6 $ expr * expr + 5$ SHIFT/REDUCE CONFLICT ???? | |
| 1995 </pre> | |
| 1996 </blockquote> | |
| 1997 | |
| 1998 In this case, when the parser reaches step 6, it has two options. One | |
| 1999 is to reduce the rule <tt>expr : expr * expr</tt> on the stack. The | |
| 2000 other option is to shift the token <tt>+</tt> on the stack. Both | |
| 2001 options are perfectly legal from the rules of the | |
| 2002 context-free-grammar. | |
| 2003 | |
| 2004 <p> | |
| 2005 By default, all shift/reduce conflicts are resolved in favor of | |
| 2006 shifting. Therefore, in the above example, the parser will always | |
| 2007 shift the <tt>+</tt> instead of reducing. Although this strategy | |
| 2008 works in many cases (for example, the case of | |
| 2009 "if-then" versus "if-then-else"), it is not enough for arithmetic expressions. In fact, | |
| 2010 in the above example, the decision to shift <tt>+</tt> is completely | |
| 2011 wrong---we should have reduced <tt>expr * expr</tt> since | |
| 2012 multiplication has higher mathematical precedence than addition. | |
| 2013 | |
| 2014 <p>To resolve ambiguity, especially in expression | |
| 2015 grammars, <tt>yacc.py</tt> allows individual tokens to be assigned a | |
| 2016 precedence level and associativity. This is done by adding a variable | |
| 2017 <tt>precedence</tt> to the grammar file like this: | |
| 2018 | |
| 2019 <blockquote> | |
| 2020 <pre> | |
| 2021 precedence = ( | |
| 2022 ('left', 'PLUS', 'MINUS'), | |
| 2023 ('left', 'TIMES', 'DIVIDE'), | |
| 2024 ) | |
| 2025 </pre> | |
| 2026 </blockquote> | |
| 2027 | |
| 2028 This declaration specifies that <tt>PLUS</tt>/<tt>MINUS</tt> have the | |
| 2029 same precedence level and are left-associative and that | |
| 2030 <tt>TIMES</tt>/<tt>DIVIDE</tt> have the same precedence and are | |
| 2031 left-associative. Within the <tt>precedence</tt> declaration, tokens | |
| 2032 are ordered from lowest to highest precedence. Thus, this declaration | |
| 2033 specifies that <tt>TIMES</tt>/<tt>DIVIDE</tt> have higher precedence | |
| 2034 than <tt>PLUS</tt>/<tt>MINUS</tt> (since they appear later in the | |
| 2035 precedence specification). | |
| 2036 | |
| 2037 <p> | |
| 2038 The precedence specification works by associating a numerical | |
| 2039 precedence level value and associativity direction to the listed | |
| 2040 tokens. For example, in the above example you get: | |
| 2041 | |
| 2042 <blockquote> | |
| 2043 <pre> | |
| 2044 PLUS : level = 1, assoc = 'left' | |
| 2045 MINUS : level = 1, assoc = 'left' | |
| 2046 TIMES : level = 2, assoc = 'left' | |
| 2047 DIVIDE : level = 2, assoc = 'left' | |
| 2048 </pre> | |
| 2049 </blockquote> | |
| 2050 | |
| 2051 These values are then used to attach a numerical precedence value and | |
| 2052 associativity direction to each grammar rule. <em>This is always | |
| 2053 determined by looking at the precedence of the right-most terminal | |
| 2054 symbol.</em> For example: | |
| 2055 | |
| 2056 <blockquote> | |
| 2057 <pre> | |
| 2058 expression : expression PLUS expression # level = 1, left | |
| 2059 | expression MINUS expression # level = 1, left | |
| 2060 | expression TIMES expression # level = 2, left | |
| 2061 | expression DIVIDE expression # level = 2, left | |
| 2062 | LPAREN expression RPAREN # level = None (not specified) | |
| 2063 | NUMBER # level = None (not specified) | |
| 2064 </pre> | |
| 2065 </blockquote> | |
| 2066 | |
| 2067 When shift/reduce conflicts are encountered, the parser generator resolves the conflict by | |
| 2068 looking at the precedence rules and associativity specifiers. | |
| 2069 | |
| 2070 <p> | |
| 2071 <ol> | |
| 2072 <li>If the current token has higher precedence than the rule on the stack, it is shifted. | |
| 2073 <li>If the grammar rule on the stack has higher precedence, the rule is reduced. | |
| 2074 <li>If the current token and the grammar rule have the same precedence, the | |
| 2075 rule is reduced for left associativity, whereas the token is shifted for right associativity. | |
| 2076 <li>If nothing is known about the precedence, shift/reduce conflicts are resolved in | |
| 2077 favor of shifting (the default). | |
| 2078 </ol> | |
| 2079 | |
| 2080 For example, if "expression PLUS expression" has been parsed and the | |
| 2081 next token is "TIMES", the action is going to be a shift because | |
| 2082 "TIMES" has a higher precedence level than "PLUS". On the other hand, | |
| 2083 if "expression TIMES expression" has been parsed and the next token is | |
| 2084 "PLUS", the action is going to be reduce because "PLUS" has a lower | |
| 2085 precedence than "TIMES." | |
| 2086 | |
| 2087 <p> | |
| 2088 When shift/reduce conflicts are resolved using the first three | |
| 2089 techniques (with the help of precedence rules), <tt>yacc.py</tt> will | |
| 2090 report no errors or conflicts in the grammar (although it will print | |
| 2091 some information in the <tt>parser.out</tt> debugging file). | |
| 2092 | |
| 2093 <p> | |
| 2094 One problem with the precedence specifier technique is that it is | |
| 2095 sometimes necessary to change the precedence of an operator in certain | |
| 2096 contexts. For example, consider a unary-minus operator in "3 + 4 * | |
| 2097 -5". Mathematically, the unary minus is normally given a very high | |
| 2098 precedence--being evaluated before the multiply. However, in our | |
| 2099 precedence specifier, MINUS has a lower precedence than TIMES. To | |
| 2100 deal with this, precedence rules can be given for so-called "fictitious tokens" | |
| 2101 like this: | |
| 2102 | |
| 2103 <blockquote> | |
| 2104 <pre> | |
| 2105 precedence = ( | |
| 2106 ('left', 'PLUS', 'MINUS'), | |
| 2107 ('left', 'TIMES', 'DIVIDE'), | |
| 2108 ('right', 'UMINUS'), # Unary minus operator | |
| 2109 ) | |
| 2110 </pre> | |
| 2111 </blockquote> | |
| 2112 | |
| 2113 Now, in the grammar file, we can write our unary minus rule like this: | |
| 2114 | |
| 2115 <blockquote> | |
| 2116 <pre> | |
| 2117 def p_expr_uminus(p): | |
| 2118 'expression : MINUS expression %prec UMINUS' | |
| 2119 p[0] = -p[2] | |
| 2120 </pre> | |
| 2121 </blockquote> | |
| 2122 | |
| 2123 In this case, <tt>%prec UMINUS</tt> overrides the default rule precedence--setting it to that | |
| 2124 of UMINUS in the precedence specifier. | |
| 2125 | |
| 2126 <p> | |
| 2127 At first, the use of UMINUS in this example may appear very confusing. | |
| 2128 UMINUS is not an input token or a grammar rule. Instead, you should | |
| 2129 think of it as the name of a special marker in the precedence table. When you use the <tt>%prec</tt> qualifier, you're simply | |
| 2130 telling yacc that you want the precedence of the expression to be the same as for this special marker instead of the usual precedence. | |
| 2131 | |
| 2132 <p> | |
| 2133 It is also possible to specify non-associativity in the <tt>precedence</tt> table. This would | |
| 2134 be used when you <em>don't</em> want operations to chain together. For example, suppose | |
| 2135 you wanted to support comparison operators like <tt><</tt> and <tt>></tt> but you didn't want to allow | |
| 2136 combinations like <tt>a < b < c</tt>. To do this, simply specify a rule like this: | |
| 2137 | |
| 2138 <blockquote> | |
| 2139 <pre> | |
| 2140 precedence = ( | |
| 2141 ('nonassoc', 'LESSTHAN', 'GREATERTHAN'), # Nonassociative operators | |
| 2142 ('left', 'PLUS', 'MINUS'), | |
| 2143 ('left', 'TIMES', 'DIVIDE'), | |
| 2144 ('right', 'UMINUS'), # Unary minus operator | |
| 2145 ) | |
| 2146 </pre> | |
| 2147 </blockquote> | |
| 2148 | |
| 2149 <p> | |
| 2150 If you do this, the occurrence of input text such as <tt> a < b < c</tt> will result in a syntax error. However, simple | |
| 2151 expressions such as <tt>a < b</tt> will still be fine. | |
| 2152 | |
| 2153 <p> | |
| 2154 Reduce/reduce conflicts are caused when there are multiple grammar | |
| 2155 rules that can be applied to a given set of symbols. This kind of | |
| 2156 conflict is almost always bad and is always resolved by picking the | |
| 2157 rule that appears first in the grammar file. Reduce/reduce conflicts | |
| 2158 are almost always caused when different sets of grammar rules somehow | |
| 2159 generate the same set of symbols. For example: | |
| 2160 | |
| 2161 <blockquote> | |
| 2162 <pre> | |
| 2163 assignment : ID EQUALS NUMBER | |
| 2164 | ID EQUALS expression | |
| 2165 | |
| 2166 expression : expression PLUS expression | |
| 2167 | expression MINUS expression | |
| 2168 | expression TIMES expression | |
| 2169 | expression DIVIDE expression | |
| 2170 | LPAREN expression RPAREN | |
| 2171 | NUMBER | |
| 2172 </pre> | |
| 2173 </blockquote> | |
| 2174 | |
| 2175 In this case, a reduce/reduce conflict exists between these two rules: | |
| 2176 | |
| 2177 <blockquote> | |
| 2178 <pre> | |
| 2179 assignment : ID EQUALS NUMBER | |
| 2180 expression : NUMBER | |
| 2181 </pre> | |
| 2182 </blockquote> | |
| 2183 | |
| 2184 For example, if you wrote "a = 5", the parser can't figure out if this | |
| 2185 is supposed to be reduced as <tt>assignment : ID EQUALS NUMBER</tt> or | |
| 2186 whether it's supposed to reduce the 5 as an expression and then reduce | |
| 2187 the rule <tt>assignment : ID EQUALS expression</tt>. | |
| 2188 | |
| 2189 <p> | |
| 2190 It should be noted that reduce/reduce conflicts are notoriously | |
| 2191 difficult to spot simply looking at the input grammar. When a | |
| 2192 reduce/reduce conflict occurs, <tt>yacc()</tt> will try to help by | |
| 2193 printing a warning message such as this: | |
| 2194 | |
| 2195 <blockquote> | |
| 2196 <pre> | |
| 2197 WARNING: 1 reduce/reduce conflict | |
| 2198 WARNING: reduce/reduce conflict in state 15 resolved using rule (assignment -> ID EQUALS NUMBER) | |
| 2199 WARNING: rejected rule (expression -> NUMBER) | |
| 2200 </pre> | |
| 2201 </blockquote> | |
| 2202 | |
| 2203 This message identifies the two rules that are in conflict. However, | |
| 2204 it may not tell you how the parser arrived at such a state. To try | |
| 2205 and figure it out, you'll probably have to look at your grammar and | |
| 2206 the contents of the | |
| 2207 <tt>parser.out</tt> debugging file with an appropriately high level of | |
| 2208 caffeination. | |
| 2209 | |
| 2210 <H3><a name="ply_nn28"></a>6.7 The parser.out file</H3> | |
| 2211 | |
| 2212 | |
| 2213 Tracking down shift/reduce and reduce/reduce conflicts is one of the finer pleasures of using an LR | |
| 2214 parsing algorithm. To assist in debugging, <tt>yacc.py</tt> creates a debugging file called | |
| 2215 'parser.out' when it generates the parsing table. The contents of this file look like the following: | |
| 2216 | |
| 2217 <blockquote> | |
| 2218 <pre> | |
| 2219 Unused terminals: | |
| 2220 | |
| 2221 | |
| 2222 Grammar | |
| 2223 | |
| 2224 Rule 1 expression -> expression PLUS expression | |
| 2225 Rule 2 expression -> expression MINUS expression | |
| 2226 Rule 3 expression -> expression TIMES expression | |
| 2227 Rule 4 expression -> expression DIVIDE expression | |
| 2228 Rule 5 expression -> NUMBER | |
| 2229 Rule 6 expression -> LPAREN expression RPAREN | |
| 2230 | |
| 2231 Terminals, with rules where they appear | |
| 2232 | |
| 2233 TIMES : 3 | |
| 2234 error : | |
| 2235 MINUS : 2 | |
| 2236 RPAREN : 6 | |
| 2237 LPAREN : 6 | |
| 2238 DIVIDE : 4 | |
| 2239 PLUS : 1 | |
| 2240 NUMBER : 5 | |
| 2241 | |
| 2242 Nonterminals, with rules where they appear | |
| 2243 | |
| 2244 expression : 1 1 2 2 3 3 4 4 6 0 | |
| 2245 | |
| 2246 | |
| 2247 Parsing method: LALR | |
| 2248 | |
| 2249 | |
| 2250 state 0 | |
| 2251 | |
| 2252 S' -> . expression | |
| 2253 expression -> . expression PLUS expression | |
| 2254 expression -> . expression MINUS expression | |
| 2255 expression -> . expression TIMES expression | |
| 2256 expression -> . expression DIVIDE expression | |
| 2257 expression -> . NUMBER | |
| 2258 expression -> . LPAREN expression RPAREN | |
| 2259 | |
| 2260 NUMBER shift and go to state 3 | |
| 2261 LPAREN shift and go to state 2 | |
| 2262 | |
| 2263 | |
| 2264 state 1 | |
| 2265 | |
| 2266 S' -> expression . | |
| 2267 expression -> expression . PLUS expression | |
| 2268 expression -> expression . MINUS expression | |
| 2269 expression -> expression . TIMES expression | |
| 2270 expression -> expression . DIVIDE expression | |
| 2271 | |
| 2272 PLUS shift and go to state 6 | |
| 2273 MINUS shift and go to state 5 | |
| 2274 TIMES shift and go to state 4 | |
| 2275 DIVIDE shift and go to state 7 | |
| 2276 | |
| 2277 | |
| 2278 state 2 | |
| 2279 | |
| 2280 expression -> LPAREN . expression RPAREN | |
| 2281 expression -> . expression PLUS expression | |
| 2282 expression -> . expression MINUS expression | |
| 2283 expression -> . expression TIMES expression | |
| 2284 expression -> . expression DIVIDE expression | |
| 2285 expression -> . NUMBER | |
| 2286 expression -> . LPAREN expression RPAREN | |
| 2287 | |
| 2288 NUMBER shift and go to state 3 | |
| 2289 LPAREN shift and go to state 2 | |
| 2290 | |
| 2291 | |
| 2292 state 3 | |
| 2293 | |
| 2294 expression -> NUMBER . | |
| 2295 | |
| 2296 $ reduce using rule 5 | |
| 2297 PLUS reduce using rule 5 | |
| 2298 MINUS reduce using rule 5 | |
| 2299 TIMES reduce using rule 5 | |
| 2300 DIVIDE reduce using rule 5 | |
| 2301 RPAREN reduce using rule 5 | |
| 2302 | |
| 2303 | |
| 2304 state 4 | |
| 2305 | |
| 2306 expression -> expression TIMES . expression | |
| 2307 expression -> . expression PLUS expression | |
| 2308 expression -> . expression MINUS expression | |
| 2309 expression -> . expression TIMES expression | |
| 2310 expression -> . expression DIVIDE expression | |
| 2311 expression -> . NUMBER | |
| 2312 expression -> . LPAREN expression RPAREN | |
| 2313 | |
| 2314 NUMBER shift and go to state 3 | |
| 2315 LPAREN shift and go to state 2 | |
| 2316 | |
| 2317 | |
| 2318 state 5 | |
| 2319 | |
| 2320 expression -> expression MINUS . expression | |
| 2321 expression -> . expression PLUS expression | |
| 2322 expression -> . expression MINUS expression | |
| 2323 expression -> . expression TIMES expression | |
| 2324 expression -> . expression DIVIDE expression | |
| 2325 expression -> . NUMBER | |
| 2326 expression -> . LPAREN expression RPAREN | |
| 2327 | |
| 2328 NUMBER shift and go to state 3 | |
| 2329 LPAREN shift and go to state 2 | |
| 2330 | |
| 2331 | |
| 2332 state 6 | |
| 2333 | |
| 2334 expression -> expression PLUS . expression | |
| 2335 expression -> . expression PLUS expression | |
| 2336 expression -> . expression MINUS expression | |
| 2337 expression -> . expression TIMES expression | |
| 2338 expression -> . expression DIVIDE expression | |
| 2339 expression -> . NUMBER | |
| 2340 expression -> . LPAREN expression RPAREN | |
| 2341 | |
| 2342 NUMBER shift and go to state 3 | |
| 2343 LPAREN shift and go to state 2 | |
| 2344 | |
| 2345 | |
| 2346 state 7 | |
| 2347 | |
| 2348 expression -> expression DIVIDE . expression | |
| 2349 expression -> . expression PLUS expression | |
| 2350 expression -> . expression MINUS expression | |
| 2351 expression -> . expression TIMES expression | |
| 2352 expression -> . expression DIVIDE expression | |
| 2353 expression -> . NUMBER | |
| 2354 expression -> . LPAREN expression RPAREN | |
| 2355 | |
| 2356 NUMBER shift and go to state 3 | |
| 2357 LPAREN shift and go to state 2 | |
| 2358 | |
| 2359 | |
| 2360 state 8 | |
| 2361 | |
| 2362 expression -> LPAREN expression . RPAREN | |
| 2363 expression -> expression . PLUS expression | |
| 2364 expression -> expression . MINUS expression | |
| 2365 expression -> expression . TIMES expression | |
| 2366 expression -> expression . DIVIDE expression | |
| 2367 | |
| 2368 RPAREN shift and go to state 13 | |
| 2369 PLUS shift and go to state 6 | |
| 2370 MINUS shift and go to state 5 | |
| 2371 TIMES shift and go to state 4 | |
| 2372 DIVIDE shift and go to state 7 | |
| 2373 | |
| 2374 | |
| 2375 state 9 | |
| 2376 | |
| 2377 expression -> expression TIMES expression . | |
| 2378 expression -> expression . PLUS expression | |
| 2379 expression -> expression . MINUS expression | |
| 2380 expression -> expression . TIMES expression | |
| 2381 expression -> expression . DIVIDE expression | |
| 2382 | |
| 2383 $ reduce using rule 3 | |
| 2384 PLUS reduce using rule 3 | |
| 2385 MINUS reduce using rule 3 | |
| 2386 TIMES reduce using rule 3 | |
| 2387 DIVIDE reduce using rule 3 | |
| 2388 RPAREN reduce using rule 3 | |
| 2389 | |
| 2390 ! PLUS [ shift and go to state 6 ] | |
| 2391 ! MINUS [ shift and go to state 5 ] | |
| 2392 ! TIMES [ shift and go to state 4 ] | |
| 2393 ! DIVIDE [ shift and go to state 7 ] | |
| 2394 | |
| 2395 state 10 | |
| 2396 | |
| 2397 expression -> expression MINUS expression . | |
| 2398 expression -> expression . PLUS expression | |
| 2399 expression -> expression . MINUS expression | |
| 2400 expression -> expression . TIMES expression | |
| 2401 expression -> expression . DIVIDE expression | |
| 2402 | |
| 2403 $ reduce using rule 2 | |
| 2404 PLUS reduce using rule 2 | |
| 2405 MINUS reduce using rule 2 | |
| 2406 RPAREN reduce using rule 2 | |
| 2407 TIMES shift and go to state 4 | |
| 2408 DIVIDE shift and go to state 7 | |
| 2409 | |
| 2410 ! TIMES [ reduce using rule 2 ] | |
| 2411 ! DIVIDE [ reduce using rule 2 ] | |
| 2412 ! PLUS [ shift and go to state 6 ] | |
| 2413 ! MINUS [ shift and go to state 5 ] | |
| 2414 | |
| 2415 state 11 | |
| 2416 | |
| 2417 expression -> expression PLUS expression . | |
| 2418 expression -> expression . PLUS expression | |
| 2419 expression -> expression . MINUS expression | |
| 2420 expression -> expression . TIMES expression | |
| 2421 expression -> expression . DIVIDE expression | |
| 2422 | |
| 2423 $ reduce using rule 1 | |
| 2424 PLUS reduce using rule 1 | |
| 2425 MINUS reduce using rule 1 | |
| 2426 RPAREN reduce using rule 1 | |
| 2427 TIMES shift and go to state 4 | |
| 2428 DIVIDE shift and go to state 7 | |
| 2429 | |
| 2430 ! TIMES [ reduce using rule 1 ] | |
| 2431 ! DIVIDE [ reduce using rule 1 ] | |
| 2432 ! PLUS [ shift and go to state 6 ] | |
| 2433 ! MINUS [ shift and go to state 5 ] | |
| 2434 | |
| 2435 state 12 | |
| 2436 | |
| 2437 expression -> expression DIVIDE expression . | |
| 2438 expression -> expression . PLUS expression | |
| 2439 expression -> expression . MINUS expression | |
| 2440 expression -> expression . TIMES expression | |
| 2441 expression -> expression . DIVIDE expression | |
| 2442 | |
| 2443 $ reduce using rule 4 | |
| 2444 PLUS reduce using rule 4 | |
| 2445 MINUS reduce using rule 4 | |
| 2446 TIMES reduce using rule 4 | |
| 2447 DIVIDE reduce using rule 4 | |
| 2448 RPAREN reduce using rule 4 | |
| 2449 | |
| 2450 ! PLUS [ shift and go to state 6 ] | |
| 2451 ! MINUS [ shift and go to state 5 ] | |
| 2452 ! TIMES [ shift and go to state 4 ] | |
| 2453 ! DIVIDE [ shift and go to state 7 ] | |
| 2454 | |
| 2455 state 13 | |
| 2456 | |
| 2457 expression -> LPAREN expression RPAREN . | |
| 2458 | |
| 2459 $ reduce using rule 6 | |
| 2460 PLUS reduce using rule 6 | |
| 2461 MINUS reduce using rule 6 | |
| 2462 TIMES reduce using rule 6 | |
| 2463 DIVIDE reduce using rule 6 | |
| 2464 RPAREN reduce using rule 6 | |
| 2465 </pre> | |
| 2466 </blockquote> | |
| 2467 | |
| 2468 The different states that appear in this file are a representation of | |
| 2469 every possible sequence of valid input tokens allowed by the grammar. | |
| 2470 When receiving input tokens, the parser is building up a stack and | |
| 2471 looking for matching rules. Each state keeps track of the grammar | |
| 2472 rules that might be in the process of being matched at that point. Within each | |
| 2473 rule, the "." character indicates the current location of the parse | |
| 2474 within that rule. In addition, the actions for each valid input token | |
| 2475 are listed. When a shift/reduce or reduce/reduce conflict arises, | |
| 2476 rules <em>not</em> selected are prefixed with an !. For example: | |
| 2477 | |
| 2478 <blockquote> | |
| 2479 <pre> | |
| 2480 ! TIMES [ reduce using rule 2 ] | |
| 2481 ! DIVIDE [ reduce using rule 2 ] | |
| 2482 ! PLUS [ shift and go to state 6 ] | |
| 2483 ! MINUS [ shift and go to state 5 ] | |
| 2484 </pre> | |
| 2485 </blockquote> | |
| 2486 | |
| 2487 By looking at these rules (and with a little practice), you can usually track down the source | |
| 2488 of most parsing conflicts. It should also be stressed that not all shift-reduce conflicts are | |
| 2489 bad. However, the only way to be sure that they are resolved correctly is to look at <tt>parser.out</tt>. | |
| 2490 | |
| 2491 <H3><a name="ply_nn29"></a>6.8 Syntax Error Handling</H3> | |
| 2492 | |
| 2493 | |
| 2494 If you are creating a parser for production use, the handling of | |
| 2495 syntax errors is important. As a general rule, you don't want a | |
| 2496 parser to simply throw up its hands and stop at the first sign of | |
| 2497 trouble. Instead, you want it to report the error, recover if possible, and | |
| 2498 continue parsing so that all of the errors in the input get reported | |
| 2499 to the user at once. This is the standard behavior found in compilers | |
| 2500 for languages such as C, C++, and Java. | |
| 2501 | |
| 2502 In PLY, when a syntax error occurs during parsing, the error is immediately | |
| 2503 detected (i.e., the parser does not read any more tokens beyond the | |
| 2504 source of the error). However, at this point, the parser enters a | |
| 2505 recovery mode that can be used to try and continue further parsing. | |
| 2506 As a general rule, error recovery in LR parsers is a delicate | |
| 2507 topic that involves ancient rituals and black-magic. The recovery mechanism | |
| 2508 provided by <tt>yacc.py</tt> is comparable to Unix yacc so you may want | |
| 2509 consult a book like O'Reilly's "Lex and Yacc" for some of the finer details. | |
| 2510 | |
| 2511 <p> | |
| 2512 When a syntax error occurs, <tt>yacc.py</tt> performs the following steps: | |
| 2513 | |
| 2514 <ol> | |
| 2515 <li>On the first occurrence of an error, the user-defined <tt>p_error()</tt> function | |
| 2516 is called with the offending token as an argument. However, if the syntax error is due to | |
| 2517 reaching the end-of-file, <tt>p_error()</tt> is called with an | |
| 2518 argument of <tt>None</tt>. | |
| 2519 Afterwards, the parser enters | |
| 2520 an "error-recovery" mode in which it will not make future calls to <tt>p_error()</tt> until it | |
| 2521 has successfully shifted at least 3 tokens onto the parsing stack. | |
| 2522 | |
| 2523 <p> | |
| 2524 <li>If no recovery action is taken in <tt>p_error()</tt>, the offending lookahead token is replaced | |
| 2525 with a special <tt>error</tt> token. | |
| 2526 | |
| 2527 <p> | |
| 2528 <li>If the offending lookahead token is already set to <tt>error</tt>, the top item of the parsing stack is | |
| 2529 deleted. | |
| 2530 | |
| 2531 <p> | |
| 2532 <li>If the entire parsing stack is unwound, the parser enters a restart state and attempts to start | |
| 2533 parsing from its initial state. | |
| 2534 | |
| 2535 <p> | |
| 2536 <li>If a grammar rule accepts <tt>error</tt> as a token, it will be | |
| 2537 shifted onto the parsing stack. | |
| 2538 | |
| 2539 <p> | |
| 2540 <li>If the top item of the parsing stack is <tt>error</tt>, lookahead tokens will be discarded until the | |
| 2541 parser can successfully shift a new symbol or reduce a rule involving <tt>error</tt>. | |
| 2542 </ol> | |
| 2543 | |
| 2544 <H4><a name="ply_nn30"></a>6.8.1 Recovery and resynchronization with error rules</H4> | |
| 2545 | |
| 2546 | |
| 2547 The most well-behaved approach for handling syntax errors is to write grammar rules that include the <tt>error</tt> | |
| 2548 token. For example, suppose your language had a grammar rule for a print statement like this: | |
| 2549 | |
| 2550 <blockquote> | |
| 2551 <pre> | |
| 2552 def p_statement_print(p): | |
| 2553 'statement : PRINT expr SEMI' | |
| 2554 ... | |
| 2555 </pre> | |
| 2556 </blockquote> | |
| 2557 | |
| 2558 To account for the possibility of a bad expression, you might write an additional grammar rule like this: | |
| 2559 | |
| 2560 <blockquote> | |
| 2561 <pre> | |
| 2562 def p_statement_print_error(p): | |
| 2563 'statement : PRINT error SEMI' | |
| 2564 print("Syntax error in print statement. Bad expression") | |
| 2565 | |
| 2566 </pre> | |
| 2567 </blockquote> | |
| 2568 | |
| 2569 In this case, the <tt>error</tt> token will match any sequence of | |
| 2570 tokens that might appear up to the first semicolon that is | |
| 2571 encountered. Once the semicolon is reached, the rule will be | |
| 2572 invoked and the <tt>error</tt> token will go away. | |
| 2573 | |
| 2574 <p> | |
| 2575 This type of recovery is sometimes known as parser resynchronization. | |
| 2576 The <tt>error</tt> token acts as a wildcard for any bad input text and | |
| 2577 the token immediately following <tt>error</tt> acts as a | |
| 2578 synchronization token. | |
| 2579 | |
| 2580 <p> | |
| 2581 It is important to note that the <tt>error</tt> token usually does not appear as the last token | |
| 2582 on the right in an error rule. For example: | |
| 2583 | |
| 2584 <blockquote> | |
| 2585 <pre> | |
| 2586 def p_statement_print_error(p): | |
| 2587 'statement : PRINT error' | |
| 2588 print("Syntax error in print statement. Bad expression") | |
| 2589 </pre> | |
| 2590 </blockquote> | |
| 2591 | |
| 2592 This is because the first bad token encountered will cause the rule to | |
| 2593 be reduced--which may make it difficult to recover if more bad tokens | |
| 2594 immediately follow. | |
| 2595 | |
| 2596 <H4><a name="ply_nn31"></a>6.8.2 Panic mode recovery</H4> | |
| 2597 | |
| 2598 | |
| 2599 An alternative error recovery scheme is to enter a panic mode recovery in which tokens are | |
| 2600 discarded to a point where the parser might be able to recover in some sensible manner. | |
| 2601 | |
| 2602 <p> | |
| 2603 Panic mode recovery is implemented entirely in the <tt>p_error()</tt> function. For example, this | |
| 2604 function starts discarding tokens until it reaches a closing '}'. Then, it restarts the | |
| 2605 parser in its initial state. | |
| 2606 | |
| 2607 <blockquote> | |
| 2608 <pre> | |
| 2609 def p_error(p): | |
| 2610 print("Whoa. You are seriously hosed.") | |
| 2611 if not p: | |
| 2612 print("End of File!") | |
| 2613 return | |
| 2614 | |
| 2615 # Read ahead looking for a closing '}' | |
| 2616 while True: | |
| 2617 tok = parser.token() # Get the next token | |
| 2618 if not tok or tok.type == 'RBRACE': | |
| 2619 break | |
| 2620 parser.restart() | |
| 2621 </pre> | |
| 2622 </blockquote> | |
| 2623 | |
| 2624 <p> | |
| 2625 This function simply discards the bad token and tells the parser that the error was ok. | |
| 2626 | |
| 2627 <blockquote> | |
| 2628 <pre> | |
| 2629 def p_error(p): | |
| 2630 if p: | |
| 2631 print("Syntax error at token", p.type) | |
| 2632 # Just discard the token and tell the parser it's okay. | |
| 2633 parser.errok() | |
| 2634 else: | |
| 2635 print("Syntax error at EOF") | |
| 2636 </pre> | |
| 2637 </blockquote> | |
| 2638 | |
| 2639 <P> | |
| 2640 More information on these methods is as follows: | |
| 2641 </p> | |
| 2642 | |
| 2643 <p> | |
| 2644 <ul> | |
| 2645 <li><tt>parser.errok()</tt>. This resets the parser state so it doesn't think it's in error-recovery | |
| 2646 mode. This will prevent an <tt>error</tt> token from being generated and will reset the internal | |
| 2647 error counters so that the next syntax error will call <tt>p_error()</tt> again. | |
| 2648 | |
| 2649 <p> | |
| 2650 <li><tt>parser.token()</tt>. This returns the next token on the input stream. | |
| 2651 | |
| 2652 <p> | |
| 2653 <li><tt>parser.restart()</tt>. This discards the entire parsing stack and resets the parser | |
| 2654 to its initial state. | |
| 2655 </ul> | |
| 2656 | |
| 2657 <p> | |
| 2658 To supply the next lookahead token to the parser, <tt>p_error()</tt> can return a token. This might be | |
| 2659 useful if trying to synchronize on special characters. For example: | |
| 2660 | |
| 2661 <blockquote> | |
| 2662 <pre> | |
| 2663 def p_error(p): | |
| 2664 # Read ahead looking for a terminating ";" | |
| 2665 while True: | |
| 2666 tok = parser.token() # Get the next token | |
| 2667 if not tok or tok.type == 'SEMI': break | |
| 2668 parser.errok() | |
| 2669 | |
| 2670 # Return SEMI to the parser as the next lookahead token | |
| 2671 return tok | |
| 2672 </pre> | |
| 2673 </blockquote> | |
| 2674 | |
| 2675 <p> | |
| 2676 Keep in mind in that the above error handling functions, | |
| 2677 <tt>parser</tt> is an instance of the parser created by | |
| 2678 <tt>yacc()</tt>. You'll need to save this instance someplace in your | |
| 2679 code so that you can refer to it during error handling. | |
| 2680 </p> | |
| 2681 | |
| 2682 <H4><a name="ply_nn35"></a>6.8.3 Signalling an error from a production</H4> | |
| 2683 | |
| 2684 | |
| 2685 If necessary, a production rule can manually force the parser to enter error recovery. This | |
| 2686 is done by raising the <tt>SyntaxError</tt> exception like this: | |
| 2687 | |
| 2688 <blockquote> | |
| 2689 <pre> | |
| 2690 def p_production(p): | |
| 2691 'production : some production ...' | |
| 2692 raise SyntaxError | |
| 2693 </pre> | |
| 2694 </blockquote> | |
| 2695 | |
| 2696 The effect of raising <tt>SyntaxError</tt> is the same as if the last symbol shifted onto the | |
| 2697 parsing stack was actually a syntax error. Thus, when you do this, the last symbol shifted is popped off | |
| 2698 of the parsing stack and the current lookahead token is set to an <tt>error</tt> token. The parser | |
| 2699 then enters error-recovery mode where it tries to reduce rules that can accept <tt>error</tt> tokens. | |
| 2700 The steps that follow from this point are exactly the same as if a syntax error were detected and | |
| 2701 <tt>p_error()</tt> were called. | |
| 2702 | |
| 2703 <P> | |
| 2704 One important aspect of manually setting an error is that the <tt>p_error()</tt> function will <b>NOT</b> be | |
| 2705 called in this case. If you need to issue an error message, make sure you do it in the production that | |
| 2706 raises <tt>SyntaxError</tt>. | |
| 2707 | |
| 2708 <P> | |
| 2709 Note: This feature of PLY is meant to mimic the behavior of the YYERROR macro in yacc. | |
| 2710 | |
| 2711 <H4><a name="ply_nn38"></a>6.8.4 When Do Syntax Errors Get Reported</H4> | |
| 2712 | |
| 2713 | |
| 2714 <p> | |
| 2715 In most cases, yacc will handle errors as soon as a bad input token is | |
| 2716 detected on the input. However, be aware that yacc may choose to | |
| 2717 delay error handling until after it has reduced one or more grammar | |
| 2718 rules first. This behavior might be unexpected, but it's related to | |
| 2719 special states in the underlying parsing table known as "defaulted | |
| 2720 states." A defaulted state is parsing condition where the same | |
| 2721 grammar rule will be reduced regardless of what <em>valid</em> token | |
| 2722 comes next on the input. For such states, yacc chooses to go ahead | |
| 2723 and reduce the grammar rule <em>without reading the next input | |
| 2724 token</em>. If the next token is bad, yacc will eventually get around to reading it and | |
| 2725 report a syntax error. It's just a little unusual in that you might | |
| 2726 see some of your grammar rules firing immediately prior to the syntax | |
| 2727 error. | |
| 2728 </p> | |
| 2729 | |
| 2730 <p> | |
| 2731 Usually, the delayed error reporting with defaulted states is harmless | |
| 2732 (and there are other reasons for wanting PLY to behave in this way). | |
| 2733 However, if you need to turn this behavior off for some reason. You | |
| 2734 can clear the defaulted states table like this: | |
| 2735 </p> | |
| 2736 | |
| 2737 <blockquote> | |
| 2738 <pre> | |
| 2739 parser = yacc.yacc() | |
| 2740 parser.defaulted_states = {} | |
| 2741 </pre> | |
| 2742 </blockquote> | |
| 2743 | |
| 2744 <p> | |
| 2745 Disabling defaulted states is not recommended if your grammar makes use | |
| 2746 of embedded actions as described in Section 6.11.</p> | |
| 2747 | |
| 2748 <H4><a name="ply_nn32"></a>6.8.5 General comments on error handling</H4> | |
| 2749 | |
| 2750 | |
| 2751 For normal types of languages, error recovery with error rules and resynchronization characters is probably the most reliable | |
| 2752 technique. This is because you can instrument the grammar to catch errors at selected places where it is relatively easy | |
| 2753 to recover and continue parsing. Panic mode recovery is really only useful in certain specialized applications where you might want | |
| 2754 to discard huge portions of the input text to find a valid restart point. | |
| 2755 | |
| 2756 <H3><a name="ply_nn33"></a>6.9 Line Number and Position Tracking</H3> | |
| 2757 | |
| 2758 | |
| 2759 Position tracking is often a tricky problem when writing compilers. | |
| 2760 By default, PLY tracks the line number and position of all tokens. | |
| 2761 This information is available using the following functions: | |
| 2762 | |
| 2763 <ul> | |
| 2764 <li><tt>p.lineno(num)</tt>. Return the line number for symbol <em>num</em> | |
| 2765 <li><tt>p.lexpos(num)</tt>. Return the lexing position for symbol <em>num</em> | |
| 2766 </ul> | |
| 2767 | |
| 2768 For example: | |
| 2769 | |
| 2770 <blockquote> | |
| 2771 <pre> | |
| 2772 def p_expression(p): | |
| 2773 'expression : expression PLUS expression' | |
| 2774 line = p.lineno(2) # line number of the PLUS token | |
| 2775 index = p.lexpos(2) # Position of the PLUS token | |
| 2776 </pre> | |
| 2777 </blockquote> | |
| 2778 | |
| 2779 As an optional feature, <tt>yacc.py</tt> can automatically track line | |
| 2780 numbers and positions for all of the grammar symbols as well. | |
| 2781 However, this extra tracking requires extra processing and can | |
| 2782 significantly slow down parsing. Therefore, it must be enabled by | |
| 2783 passing the | |
| 2784 <tt>tracking=True</tt> option to <tt>yacc.parse()</tt>. For example: | |
| 2785 | |
| 2786 <blockquote> | |
| 2787 <pre> | |
| 2788 yacc.parse(data,tracking=True) | |
| 2789 </pre> | |
| 2790 </blockquote> | |
| 2791 | |
| 2792 Once enabled, the <tt>lineno()</tt> and <tt>lexpos()</tt> methods work | |
| 2793 for all grammar symbols. In addition, two additional methods can be | |
| 2794 used: | |
| 2795 | |
| 2796 <ul> | |
| 2797 <li><tt>p.linespan(num)</tt>. Return a tuple (startline,endline) with the starting and ending line number for symbol <em>num</em>. | |
| 2798 <li><tt>p.lexspan(num)</tt>. Return a tuple (start,end) with the starting and ending positions for symbol <em>num</em>. | |
| 2799 </ul> | |
| 2800 | |
| 2801 For example: | |
| 2802 | |
| 2803 <blockquote> | |
| 2804 <pre> | |
| 2805 def p_expression(p): | |
| 2806 'expression : expression PLUS expression' | |
| 2807 p.lineno(1) # Line number of the left expression | |
| 2808 p.lineno(2) # line number of the PLUS operator | |
| 2809 p.lineno(3) # line number of the right expression | |
| 2810 ... | |
| 2811 start,end = p.linespan(3) # Start,end lines of the right expression | |
| 2812 starti,endi = p.lexspan(3) # Start,end positions of right expression | |
| 2813 | |
| 2814 </pre> | |
| 2815 </blockquote> | |
| 2816 | |
| 2817 Note: The <tt>lexspan()</tt> function only returns the range of values up to the start of the last grammar symbol. | |
| 2818 | |
| 2819 <p> | |
| 2820 Although it may be convenient for PLY to track position information on | |
| 2821 all grammar symbols, this is often unnecessary. For example, if you | |
| 2822 are merely using line number information in an error message, you can | |
| 2823 often just key off of a specific token in the grammar rule. For | |
| 2824 example: | |
| 2825 | |
| 2826 <blockquote> | |
| 2827 <pre> | |
| 2828 def p_bad_func(p): | |
| 2829 'funccall : fname LPAREN error RPAREN' | |
| 2830 # Line number reported from LPAREN token | |
| 2831 print("Bad function call at line", p.lineno(2)) | |
| 2832 </pre> | |
| 2833 </blockquote> | |
| 2834 | |
| 2835 <p> | |
| 2836 Similarly, you may get better parsing performance if you only | |
| 2837 selectively propagate line number information where it's needed using | |
| 2838 the <tt>p.set_lineno()</tt> method. For example: | |
| 2839 | |
| 2840 <blockquote> | |
| 2841 <pre> | |
| 2842 def p_fname(p): | |
| 2843 'fname : ID' | |
| 2844 p[0] = p[1] | |
| 2845 p.set_lineno(0,p.lineno(1)) | |
| 2846 </pre> | |
| 2847 </blockquote> | |
| 2848 | |
| 2849 PLY doesn't retain line number information from rules that have already been | |
| 2850 parsed. If you are building an abstract syntax tree and need to have line numbers, | |
| 2851 you should make sure that the line numbers appear in the tree itself. | |
| 2852 | |
| 2853 <H3><a name="ply_nn34"></a>6.10 AST Construction</H3> | |
| 2854 | |
| 2855 | |
| 2856 <tt>yacc.py</tt> provides no special functions for constructing an | |
| 2857 abstract syntax tree. However, such construction is easy enough to do | |
| 2858 on your own. | |
| 2859 | |
| 2860 <p>A minimal way to construct a tree is to simply create and | |
| 2861 propagate a tuple or list in each grammar rule function. There | |
| 2862 are many possible ways to do this, but one example would be something | |
| 2863 like this: | |
| 2864 | |
| 2865 <blockquote> | |
| 2866 <pre> | |
| 2867 def p_expression_binop(p): | |
| 2868 '''expression : expression PLUS expression | |
| 2869 | expression MINUS expression | |
| 2870 | expression TIMES expression | |
| 2871 | expression DIVIDE expression''' | |
| 2872 | |
| 2873 p[0] = ('binary-expression',p[2],p[1],p[3]) | |
| 2874 | |
| 2875 def p_expression_group(p): | |
| 2876 'expression : LPAREN expression RPAREN' | |
| 2877 p[0] = ('group-expression',p[2]) | |
| 2878 | |
| 2879 def p_expression_number(p): | |
| 2880 'expression : NUMBER' | |
| 2881 p[0] = ('number-expression',p[1]) | |
| 2882 </pre> | |
| 2883 </blockquote> | |
| 2884 | |
| 2885 <p> | |
| 2886 Another approach is to create a set of data structure for different | |
| 2887 kinds of abstract syntax tree nodes and assign nodes to <tt>p[0]</tt> | |
| 2888 in each rule. For example: | |
| 2889 | |
| 2890 <blockquote> | |
| 2891 <pre> | |
| 2892 class Expr: pass | |
| 2893 | |
| 2894 class BinOp(Expr): | |
| 2895 def __init__(self,left,op,right): | |
| 2896 self.type = "binop" | |
| 2897 self.left = left | |
| 2898 self.right = right | |
| 2899 self.op = op | |
| 2900 | |
| 2901 class Number(Expr): | |
| 2902 def __init__(self,value): | |
| 2903 self.type = "number" | |
| 2904 self.value = value | |
| 2905 | |
| 2906 def p_expression_binop(p): | |
| 2907 '''expression : expression PLUS expression | |
| 2908 | expression MINUS expression | |
| 2909 | expression TIMES expression | |
| 2910 | expression DIVIDE expression''' | |
| 2911 | |
| 2912 p[0] = BinOp(p[1],p[2],p[3]) | |
| 2913 | |
| 2914 def p_expression_group(p): | |
| 2915 'expression : LPAREN expression RPAREN' | |
| 2916 p[0] = p[2] | |
| 2917 | |
| 2918 def p_expression_number(p): | |
| 2919 'expression : NUMBER' | |
| 2920 p[0] = Number(p[1]) | |
| 2921 </pre> | |
| 2922 </blockquote> | |
| 2923 | |
| 2924 The advantage to this approach is that it may make it easier to attach more complicated | |
| 2925 semantics, type checking, code generation, and other features to the node classes. | |
| 2926 | |
| 2927 <p> | |
| 2928 To simplify tree traversal, it may make sense to pick a very generic | |
| 2929 tree structure for your parse tree nodes. For example: | |
| 2930 | |
| 2931 <blockquote> | |
| 2932 <pre> | |
| 2933 class Node: | |
| 2934 def __init__(self,type,children=None,leaf=None): | |
| 2935 self.type = type | |
| 2936 if children: | |
| 2937 self.children = children | |
| 2938 else: | |
| 2939 self.children = [ ] | |
| 2940 self.leaf = leaf | |
| 2941 | |
| 2942 def p_expression_binop(p): | |
| 2943 '''expression : expression PLUS expression | |
| 2944 | expression MINUS expression | |
| 2945 | expression TIMES expression | |
| 2946 | expression DIVIDE expression''' | |
| 2947 | |
| 2948 p[0] = Node("binop", [p[1],p[3]], p[2]) | |
| 2949 </pre> | |
| 2950 </blockquote> | |
| 2951 | |
| 2952 <H3><a name="ply_nn35"></a>6.11 Embedded Actions</H3> | |
| 2953 | |
| 2954 | |
| 2955 The parsing technique used by yacc only allows actions to be executed at the end of a rule. For example, | |
| 2956 suppose you have a rule like this: | |
| 2957 | |
| 2958 <blockquote> | |
| 2959 <pre> | |
| 2960 def p_foo(p): | |
| 2961 "foo : A B C D" | |
| 2962 print("Parsed a foo", p[1],p[2],p[3],p[4]) | |
| 2963 </pre> | |
| 2964 </blockquote> | |
| 2965 | |
| 2966 <p> | |
| 2967 In this case, the supplied action code only executes after all of the | |
| 2968 symbols <tt>A</tt>, <tt>B</tt>, <tt>C</tt>, and <tt>D</tt> have been | |
| 2969 parsed. Sometimes, however, it is useful to execute small code | |
| 2970 fragments during intermediate stages of parsing. For example, suppose | |
| 2971 you wanted to perform some action immediately after <tt>A</tt> has | |
| 2972 been parsed. To do this, write an empty rule like this: | |
| 2973 | |
| 2974 <blockquote> | |
| 2975 <pre> | |
| 2976 def p_foo(p): | |
| 2977 "foo : A seen_A B C D" | |
| 2978 print("Parsed a foo", p[1],p[3],p[4],p[5]) | |
| 2979 print("seen_A returned", p[2]) | |
| 2980 | |
| 2981 def p_seen_A(p): | |
| 2982 "seen_A :" | |
| 2983 print("Saw an A = ", p[-1]) # Access grammar symbol to left | |
| 2984 p[0] = some_value # Assign value to seen_A | |
| 2985 | |
| 2986 </pre> | |
| 2987 </blockquote> | |
| 2988 | |
| 2989 <p> | |
| 2990 In this example, the empty <tt>seen_A</tt> rule executes immediately | |
| 2991 after <tt>A</tt> is shifted onto the parsing stack. Within this | |
| 2992 rule, <tt>p[-1]</tt> refers to the symbol on the stack that appears | |
| 2993 immediately to the left of the <tt>seen_A</tt> symbol. In this case, | |
| 2994 it would be the value of <tt>A</tt> in the <tt>foo</tt> rule | |
| 2995 immediately above. Like other rules, a value can be returned from an | |
| 2996 embedded action by simply assigning it to <tt>p[0]</tt> | |
| 2997 | |
| 2998 <p> | |
| 2999 The use of embedded actions can sometimes introduce extra shift/reduce conflicts. For example, | |
| 3000 this grammar has no conflicts: | |
| 3001 | |
| 3002 <blockquote> | |
| 3003 <pre> | |
| 3004 def p_foo(p): | |
| 3005 """foo : abcd | |
| 3006 | abcx""" | |
| 3007 | |
| 3008 def p_abcd(p): | |
| 3009 "abcd : A B C D" | |
| 3010 | |
| 3011 def p_abcx(p): | |
| 3012 "abcx : A B C X" | |
| 3013 </pre> | |
| 3014 </blockquote> | |
| 3015 | |
| 3016 However, if you insert an embedded action into one of the rules like this, | |
| 3017 | |
| 3018 <blockquote> | |
| 3019 <pre> | |
| 3020 def p_foo(p): | |
| 3021 """foo : abcd | |
| 3022 | abcx""" | |
| 3023 | |
| 3024 def p_abcd(p): | |
| 3025 "abcd : A B C D" | |
| 3026 | |
| 3027 def p_abcx(p): | |
| 3028 "abcx : A B seen_AB C X" | |
| 3029 | |
| 3030 def p_seen_AB(p): | |
| 3031 "seen_AB :" | |
| 3032 </pre> | |
| 3033 </blockquote> | |
| 3034 | |
| 3035 an extra shift-reduce conflict will be introduced. This conflict is | |
| 3036 caused by the fact that the same symbol <tt>C</tt> appears next in | |
| 3037 both the <tt>abcd</tt> and <tt>abcx</tt> rules. The parser can either | |
| 3038 shift the symbol (<tt>abcd</tt> rule) or reduce the empty | |
| 3039 rule <tt>seen_AB</tt> (<tt>abcx</tt> rule). | |
| 3040 | |
| 3041 <p> | |
| 3042 A common use of embedded rules is to control other aspects of parsing | |
| 3043 such as scoping of local variables. For example, if you were parsing C code, you might | |
| 3044 write code like this: | |
| 3045 | |
| 3046 <blockquote> | |
| 3047 <pre> | |
| 3048 def p_statements_block(p): | |
| 3049 "statements: LBRACE new_scope statements RBRACE""" | |
| 3050 # Action code | |
| 3051 ... | |
| 3052 pop_scope() # Return to previous scope | |
| 3053 | |
| 3054 def p_new_scope(p): | |
| 3055 "new_scope :" | |
| 3056 # Create a new scope for local variables | |
| 3057 s = new_scope() | |
| 3058 push_scope(s) | |
| 3059 ... | |
| 3060 </pre> | |
| 3061 </blockquote> | |
| 3062 | |
| 3063 In this case, the embedded action <tt>new_scope</tt> executes | |
| 3064 immediately after a <tt>LBRACE</tt> (<tt>{</tt>) symbol is parsed. | |
| 3065 This might adjust internal symbol tables and other aspects of the | |
| 3066 parser. Upon completion of the rule <tt>statements_block</tt>, code | |
| 3067 might undo the operations performed in the embedded action | |
| 3068 (e.g., <tt>pop_scope()</tt>). | |
| 3069 | |
| 3070 <H3><a name="ply_nn36"></a>6.12 Miscellaneous Yacc Notes</H3> | |
| 3071 | |
| 3072 | |
| 3073 <ul> | |
| 3074 | |
| 3075 <li>By default, <tt>yacc.py</tt> relies on <tt>lex.py</tt> for tokenizing. However, an alternative tokenizer | |
| 3076 can be supplied as follows: | |
| 3077 | |
| 3078 <blockquote> | |
| 3079 <pre> | |
| 3080 parser = yacc.parse(lexer=x) | |
| 3081 </pre> | |
| 3082 </blockquote> | |
| 3083 in this case, <tt>x</tt> must be a Lexer object that minimally has a <tt>x.token()</tt> method for retrieving the next | |
| 3084 token. If an input string is given to <tt>yacc.parse()</tt>, the lexer must also have an <tt>x.input()</tt> method. | |
| 3085 | |
| 3086 <p> | |
| 3087 <li>By default, the yacc generates tables in debugging mode (which produces the parser.out file and other output). | |
| 3088 To disable this, use | |
| 3089 | |
| 3090 <blockquote> | |
| 3091 <pre> | |
| 3092 parser = yacc.yacc(debug=False) | |
| 3093 </pre> | |
| 3094 </blockquote> | |
| 3095 | |
| 3096 <p> | |
| 3097 <li>To change the name of the <tt>parsetab.py</tt> file, use: | |
| 3098 | |
| 3099 <blockquote> | |
| 3100 <pre> | |
| 3101 parser = yacc.yacc(tabmodule="foo") | |
| 3102 </pre> | |
| 3103 </blockquote> | |
| 3104 | |
| 3105 <P> | |
| 3106 Normally, the <tt>parsetab.py</tt> file is placed into the same directory as | |
| 3107 the module where the parser is defined. If you want it to go somewhere else, you can | |
| 3108 given an absolute package name for <tt>tabmodule</tt> instead. In that case, the | |
| 3109 tables will be written there. | |
| 3110 </p> | |
| 3111 | |
| 3112 <p> | |
| 3113 <li>To change the directory in which the <tt>parsetab.py</tt> file (and other output files) are written, use: | |
| 3114 <blockquote> | |
| 3115 <pre> | |
| 3116 parser = yacc.yacc(tabmodule="foo",outputdir="somedirectory") | |
| 3117 </pre> | |
| 3118 </blockquote> | |
| 3119 | |
| 3120 <p> | |
| 3121 Note: Be aware that unless the directory specified is also on Python's path (<tt>sys.path</tt>), subsequent | |
| 3122 imports of the table file will fail. As a general rule, it's better to specify a destination using the | |
| 3123 <tt>tabmodule</tt> argument instead of directly specifying a directory using the <tt>outputdir</tt> argument. | |
| 3124 </p> | |
| 3125 | |
| 3126 <p> | |
| 3127 <li>To prevent yacc from generating any kind of parser table file, use: | |
| 3128 <blockquote> | |
| 3129 <pre> | |
| 3130 parser = yacc.yacc(write_tables=False) | |
| 3131 </pre> | |
| 3132 </blockquote> | |
| 3133 | |
| 3134 Note: If you disable table generation, yacc() will regenerate the parsing tables | |
| 3135 each time it runs (which may take awhile depending on how large your grammar is). | |
| 3136 | |
| 3137 <P> | |
| 3138 <li>To print copious amounts of debugging during parsing, use: | |
| 3139 | |
| 3140 <blockquote> | |
| 3141 <pre> | |
| 3142 parser = yacc.parse(debug=True) | |
| 3143 </pre> | |
| 3144 </blockquote> | |
| 3145 | |
| 3146 <p> | |
| 3147 <li>Since the generation of the LALR tables is relatively expensive, previously generated tables are | |
| 3148 cached and reused if possible. The decision to regenerate the tables is determined by taking an MD5 | |
| 3149 checksum of all grammar rules and precedence rules. Only in the event of a mismatch are the tables regenerated. | |
| 3150 | |
| 3151 <p> | |
| 3152 It should be noted that table generation is reasonably efficient, even for grammars that involve around a 100 rules | |
| 3153 and several hundred states. </li> | |
| 3154 | |
| 3155 | |
| 3156 <p> | |
| 3157 <li>Since LR parsing is driven by tables, the performance of the parser is largely independent of the | |
| 3158 size of the grammar. The biggest bottlenecks will be the lexer and the complexity of the code in your grammar rules. | |
| 3159 </li> | |
| 3160 </p> | |
| 3161 | |
| 3162 <p> | |
| 3163 <li><tt>yacc()</tt> also allows parsers to be defined as classes and as closures (see the section on alternative specification of | |
| 3164 lexers). However, be aware that only one parser may be defined in a single module (source file). There are various | |
| 3165 error checks and validation steps that may issue confusing error messages if you try to define multiple parsers | |
| 3166 in the same source file. | |
| 3167 </li> | |
| 3168 </p> | |
| 3169 | |
| 3170 </ul> | |
| 3171 </p> | |
| 3172 | |
| 3173 | |
| 3174 <H2><a name="ply_nn37"></a>7. Multiple Parsers and Lexers</H2> | |
| 3175 | |
| 3176 | |
| 3177 In advanced parsing applications, you may want to have multiple | |
| 3178 parsers and lexers. | |
| 3179 | |
| 3180 <p> | |
| 3181 As a general rules this isn't a problem. However, to make it work, | |
| 3182 you need to carefully make sure everything gets hooked up correctly. | |
| 3183 First, make sure you save the objects returned by <tt>lex()</tt> and | |
| 3184 <tt>yacc()</tt>. For example: | |
| 3185 | |
| 3186 <blockquote> | |
| 3187 <pre> | |
| 3188 lexer = lex.lex() # Return lexer object | |
| 3189 parser = yacc.yacc() # Return parser object | |
| 3190 </pre> | |
| 3191 </blockquote> | |
| 3192 | |
| 3193 Next, when parsing, make sure you give the <tt>parse()</tt> function a reference to the lexer it | |
| 3194 should be using. For example: | |
| 3195 | |
| 3196 <blockquote> | |
| 3197 <pre> | |
| 3198 parser.parse(text,lexer=lexer) | |
| 3199 </pre> | |
| 3200 </blockquote> | |
| 3201 | |
| 3202 If you forget to do this, the parser will use the last lexer | |
| 3203 created--which is not always what you want. | |
| 3204 | |
| 3205 <p> | |
| 3206 Within lexer and parser rule functions, these objects are also | |
| 3207 available. In the lexer, the "lexer" attribute of a token refers to | |
| 3208 the lexer object that triggered the rule. For example: | |
| 3209 | |
| 3210 <blockquote> | |
| 3211 <pre> | |
| 3212 def t_NUMBER(t): | |
| 3213 r'\d+' | |
| 3214 ... | |
| 3215 print(t.lexer) # Show lexer object | |
| 3216 </pre> | |
| 3217 </blockquote> | |
| 3218 | |
| 3219 In the parser, the "lexer" and "parser" attributes refer to the lexer | |
| 3220 and parser objects respectively. | |
| 3221 | |
| 3222 <blockquote> | |
| 3223 <pre> | |
| 3224 def p_expr_plus(p): | |
| 3225 'expr : expr PLUS expr' | |
| 3226 ... | |
| 3227 print(p.parser) # Show parser object | |
| 3228 print(p.lexer) # Show lexer object | |
| 3229 </pre> | |
| 3230 </blockquote> | |
| 3231 | |
| 3232 If necessary, arbitrary attributes can be attached to the lexer or parser object. | |
| 3233 For example, if you wanted to have different parsing modes, you could attach a mode | |
| 3234 attribute to the parser object and look at it later. | |
| 3235 | |
| 3236 <H2><a name="ply_nn38"></a>8. Using Python's Optimized Mode</H2> | |
| 3237 | |
| 3238 | |
| 3239 Because PLY uses information from doc-strings, parsing and lexing | |
| 3240 information must be gathered while running the Python interpreter in | |
| 3241 normal mode (i.e., not with the -O or -OO options). However, if you | |
| 3242 specify optimized mode like this: | |
| 3243 | |
| 3244 <blockquote> | |
| 3245 <pre> | |
| 3246 lex.lex(optimize=1) | |
| 3247 yacc.yacc(optimize=1) | |
| 3248 </pre> | |
| 3249 </blockquote> | |
| 3250 | |
| 3251 then PLY can later be used when Python runs in optimized mode. To make this work, | |
| 3252 make sure you first run Python in normal mode. Once the lexing and parsing tables | |
| 3253 have been generated the first time, run Python in optimized mode. PLY will use | |
| 3254 the tables without the need for doc strings. | |
| 3255 | |
| 3256 <p> | |
| 3257 Beware: running PLY in optimized mode disables a lot of error | |
| 3258 checking. You should only do this when your project has stabilized | |
| 3259 and you don't need to do any debugging. One of the purposes of | |
| 3260 optimized mode is to substantially decrease the startup time of | |
| 3261 your compiler (by assuming that everything is already properly | |
| 3262 specified and works). | |
| 3263 | |
| 3264 <H2><a name="ply_nn44"></a>9. Advanced Debugging</H2> | |
| 3265 | |
| 3266 | |
| 3267 <p> | |
| 3268 Debugging a compiler is typically not an easy task. PLY provides some | |
| 3269 advanced diagostic capabilities through the use of Python's | |
| 3270 <tt>logging</tt> module. The next two sections describe this: | |
| 3271 | |
| 3272 <H3><a name="ply_nn45"></a>9.1 Debugging the lex() and yacc() commands</H3> | |
| 3273 | |
| 3274 | |
| 3275 <p> | |
| 3276 Both the <tt>lex()</tt> and <tt>yacc()</tt> commands have a debugging | |
| 3277 mode that can be enabled using the <tt>debug</tt> flag. For example: | |
| 3278 | |
| 3279 <blockquote> | |
| 3280 <pre> | |
| 3281 lex.lex(debug=True) | |
| 3282 yacc.yacc(debug=True) | |
| 3283 </pre> | |
| 3284 </blockquote> | |
| 3285 | |
| 3286 Normally, the output produced by debugging is routed to either | |
| 3287 standard error or, in the case of <tt>yacc()</tt>, to a file | |
| 3288 <tt>parser.out</tt>. This output can be more carefully controlled | |
| 3289 by supplying a logging object. Here is an example that adds | |
| 3290 information about where different debugging messages are coming from: | |
| 3291 | |
| 3292 <blockquote> | |
| 3293 <pre> | |
| 3294 # Set up a logging object | |
| 3295 import logging | |
| 3296 logging.basicConfig( | |
| 3297 level = logging.DEBUG, | |
| 3298 filename = "parselog.txt", | |
| 3299 filemode = "w", | |
| 3300 format = "%(filename)10s:%(lineno)4d:%(message)s" | |
| 3301 ) | |
| 3302 log = logging.getLogger() | |
| 3303 | |
| 3304 lex.lex(debug=True,debuglog=log) | |
| 3305 yacc.yacc(debug=True,debuglog=log) | |
| 3306 </pre> | |
| 3307 </blockquote> | |
| 3308 | |
| 3309 If you supply a custom logger, the amount of debugging | |
| 3310 information produced can be controlled by setting the logging level. | |
| 3311 Typically, debugging messages are either issued at the <tt>DEBUG</tt>, | |
| 3312 <tt>INFO</tt>, or <tt>WARNING</tt> levels. | |
| 3313 | |
| 3314 <p> | |
| 3315 PLY's error messages and warnings are also produced using the logging | |
| 3316 interface. This can be controlled by passing a logging object | |
| 3317 using the <tt>errorlog</tt> parameter. | |
| 3318 | |
| 3319 <blockquote> | |
| 3320 <pre> | |
| 3321 lex.lex(errorlog=log) | |
| 3322 yacc.yacc(errorlog=log) | |
| 3323 </pre> | |
| 3324 </blockquote> | |
| 3325 | |
| 3326 If you want to completely silence warnings, you can either pass in a | |
| 3327 logging object with an appropriate filter level or use the <tt>NullLogger</tt> | |
| 3328 object defined in either <tt>lex</tt> or <tt>yacc</tt>. For example: | |
| 3329 | |
| 3330 <blockquote> | |
| 3331 <pre> | |
| 3332 yacc.yacc(errorlog=yacc.NullLogger()) | |
| 3333 </pre> | |
| 3334 </blockquote> | |
| 3335 | |
| 3336 <H3><a name="ply_nn46"></a>9.2 Run-time Debugging</H3> | |
| 3337 | |
| 3338 | |
| 3339 <p> | |
| 3340 To enable run-time debugging of a parser, use the <tt>debug</tt> option to parse. This | |
| 3341 option can either be an integer (which simply turns debugging on or off) or an instance | |
| 3342 of a logger object. For example: | |
| 3343 | |
| 3344 <blockquote> | |
| 3345 <pre> | |
| 3346 log = logging.getLogger() | |
| 3347 parser.parse(input,debug=log) | |
| 3348 </pre> | |
| 3349 </blockquote> | |
| 3350 | |
| 3351 If a logging object is passed, you can use its filtering level to control how much | |
| 3352 output gets generated. The <tt>INFO</tt> level is used to produce information | |
| 3353 about rule reductions. The <tt>DEBUG</tt> level will show information about the | |
| 3354 parsing stack, token shifts, and other details. The <tt>ERROR</tt> level shows information | |
| 3355 related to parsing errors. | |
| 3356 | |
| 3357 <p> | |
| 3358 For very complicated problems, you should pass in a logging object that | |
| 3359 redirects to a file where you can more easily inspect the output after | |
| 3360 execution. | |
| 3361 | |
| 3362 <H2><a name="ply_nn49"></a>10. Packaging Advice</H2> | |
| 3363 | |
| 3364 | |
| 3365 <p> | |
| 3366 If you are distributing a package that makes use of PLY, you should | |
| 3367 spend a few moments thinking about how you want to handle the files | |
| 3368 that are automatically generated. For example, the <tt>parsetab.py</tt> | |
| 3369 file generated by the <tt>yacc()</tt> function.</p> | |
| 3370 | |
| 3371 <p> | |
| 3372 Starting in PLY-3.6, the table files are created in the same directory | |
| 3373 as the file where a parser is defined. This means that the | |
| 3374 <tt>parsetab.py</tt> file will live side-by-side with your parser | |
| 3375 specification. In terms of packaging, this is probably the easiest and | |
| 3376 most sane approach to manage. You don't need to give <tt>yacc()</tt> | |
| 3377 any extra arguments and it should just "work."</p> | |
| 3378 | |
| 3379 <p> | |
| 3380 One concern is the management of the <tt>parsetab.py</tt> file itself. | |
| 3381 For example, should you have this file checked into version control (e.g., GitHub), | |
| 3382 should it be included in a package distribution as a normal file, or should you | |
| 3383 just let PLY generate it automatically for the user when they install your package? | |
| 3384 </p> | |
| 3385 | |
| 3386 <p> | |
| 3387 As of PLY-3.6, the <tt>parsetab.py</tt> file should be compatible across all versions | |
| 3388 of Python including Python 2 and 3. Thus, a table file generated in Python 2 should | |
| 3389 work fine if it's used on Python 3. Because of this, it should be relatively harmless | |
| 3390 to distribute the <tt>parsetab.py</tt> file yourself if you need to. However, be aware | |
| 3391 that older/newer versions of PLY may try to regenerate the file if there are future | |
| 3392 enhancements or changes to its format. | |
| 3393 </p> | |
| 3394 | |
| 3395 <p> | |
| 3396 To make the generation of table files easier for the purposes of installation, you might | |
| 3397 way to make your parser files executable using the <tt>-m</tt> option or similar. For | |
| 3398 example: | |
| 3399 </p> | |
| 3400 | |
| 3401 <blockquote> | |
| 3402 <pre> | |
| 3403 # calc.py | |
| 3404 ... | |
| 3405 ... | |
| 3406 def make_parser(): | |
| 3407 parser = yacc.yacc() | |
| 3408 return parser | |
| 3409 | |
| 3410 if __name__ == '__main__': | |
| 3411 make_parser() | |
| 3412 </pre> | |
| 3413 </blockquote> | |
| 3414 | |
| 3415 <p> | |
| 3416 You can then use a command such as <tt>python -m calc.py</tt> to generate the tables. Alternatively, | |
| 3417 a <tt>setup.py</tt> script, can import the module and use <tt>make_parser()</tt> to create the | |
| 3418 parsing tables. | |
| 3419 </p> | |
| 3420 | |
| 3421 <p> | |
| 3422 If you're willing to sacrifice a little startup time, you can also instruct PLY to never write the | |
| 3423 tables using <tt>yacc.yacc(write_tables=False, debug=False)</tt>. In this mode, PLY will regenerate | |
| 3424 the parsing tables from scratch each time. For a small grammar, you probably won't notice. For a | |
| 3425 large grammar, you should probably reconsider--the parsing tables are meant to dramatically speed up this process. | |
| 3426 </p> | |
| 3427 | |
| 3428 <p> | |
| 3429 During operation, is is normal for PLY to produce diagnostic error | |
| 3430 messages (usually printed to standard error). These are generated | |
| 3431 entirely using the <tt>logging</tt> module. If you want to redirect | |
| 3432 these messages or silence them, you can provide your own logging | |
| 3433 object to <tt>yacc()</tt>. For example: | |
| 3434 </p> | |
| 3435 | |
| 3436 <blockquote> | |
| 3437 <pre> | |
| 3438 import logging | |
| 3439 log = logging.getLogger('ply') | |
| 3440 ... | |
| 3441 parser = yacc.yacc(errorlog=log) | |
| 3442 </pre> | |
| 3443 </blockquote> | |
| 3444 | |
| 3445 <H2><a name="ply_nn39"></a>11. Where to go from here?</H2> | |
| 3446 | |
| 3447 | |
| 3448 The <tt>examples</tt> directory of the PLY distribution contains several simple examples. Please consult a | |
| 3449 compilers textbook for the theory and underlying implementation details or LR parsing. | |
| 3450 | |
| 3451 </body> | |
| 3452 </html> | |
| 3453 | |
| 3454 | |
| 3455 | |
| 3456 | |
| 3457 | |
| 3458 | |
| 3459 |