doc/lemon.html

   1 <html>
   2 <head>
   3 <title>The Lemon Parser Generator</title>
   4 </head>
   5 <body>
   6 <a id="main"></a>
   7 <h1 align='center'>The Lemon Parser Generator</h1>
   8
   9 <p>Lemon is an LALR(1) parser generator for C.
  10 It does the same job as "bison" and "yacc".
  11 But Lemon is not a bison or yacc clone.  Lemon
  12 uses a different grammar syntax which is designed to
  13 reduce the number of coding errors.  Lemon also uses a
  14 parsing engine that is faster than yacc and
  15 bison and which is both reentrant and threadsafe.
  16 (Update: Since the previous sentence was written, bison
  17 has also been updated so that it too can generate a
  18 reentrant and threadsafe parser.)
  19 Lemon also implements features that can be used
  20 to eliminate resource leaks, making it suitable for use
  21 in long-running programs such as graphical user interfaces
  22 or embedded controllers.</p>
  23
  24 <p>This document is an introduction to the Lemon
  25 parser generator.</p>
  26
  27 <a id="toc"></a>
  28 <h2>1.0 Table of Contents</h2>
  29 <ul>
  30 <li><a href="#main">Introduction</a>
  31 <li><a href="#toc">1.0 Table of Contents</a>
  32 <li><a href="#secnot">2.0 Security Notes</a><br>
  33 <li><a href="#optheory">3.0 Theory of Operation</a>
  34     <ul>
  35     <li><a href="#options">3.1 Command Line Options</a>
  36     <li><a href="#interface">3.2 The Parser Interface</a>
  37         <ul>
  38         <li><a href="#onstack">3.2.1 Allocating The Parse Object On Stack</a>
  39         <li><a href="#ifsum">3.2.2 Interface Summary</a>
  40         </ul>
  41     <li><a href="#yaccdiff">3.3 Differences With YACC and BISON</a>
  42     <li><a href="#build">3.4 Building The "lemon" Or "lemon.exe" Executable</a>
  43     </ul>
  44 <li><a href="#syntax">4.0 Input File Syntax</a>
  45     <ul>
  46     <li><a href="#tnt">4.1 Terminals and Nonterminals</a>
  47     <li><a href="#rules">4.2 Grammar Rules</a>
  48     <li><a href="#precrules">4.3 Precedence Rules</a>
  49     <li><a href="#special">4.4 Special Directives</a>
  50     </ul>
  51 <li><a href="#errors">5.0 Error Processing</a>
  52 <li><a href="#history">6.0 History of Lemon</a>
  53 <li><a href="#copyright">7.0 Copyright</a>
  54 </ul>
  55
  56 <a id="secnot"></a>
  57 <h2>2.0 Security Note</h2>
  58
  59 <p>The language parser code created by Lemon is very robust and
  60 is well-suited for use in internet-facing applications that need to
  61 safely process maliciously crafted inputs.</p>
  62
  63 <p>The "lemon.exe" command-line tool itself works great when given a valid
  64 input grammar file and almost always gives helpful
  65 error messages for malformed inputs.  However,  it is possible for
  66 a malicious user to craft a grammar file that will cause
  67 lemon.exe to crash.
  68 We do not see this as a problem, as lemon.exe is not intended to be used
  69 with hostile inputs.
  70 To summarize:</p>
  71
  72 <ul>
  73 <li>Parser code generated by lemon &rarr; Robust and secure
  74 <li>The "lemon.exe" command line tool itself &rarr; Not so much
  75 </ul>
  76
  77 <a id="optheory"></a>
  78 <h2>3.0 Theory of Operation</h2>
  79
  80 <p>Lemon is computer program that translates a context free grammar (CFG)
  81 for a particular language into C code that implements a parser for
  82 that language.
  83 The Lemon program has two inputs:</p>
  84 <ul>
  85 <li>The grammar specification.
  86 <li>A parser template file.
  87 </ul>
  88 <p>Typically, only the grammar specification is supplied by the programmer.
  89 Lemon comes with a default parser template
  90 ("<a href="https://sqlite.org/src/file/tool/lempar.c">lempar.c</a>")
  91 that works fine for most applications.  But the user is free to substitute
  92 a different parser template if desired.</p>
  93
  94 <p>Depending on command-line options, Lemon will generate up to
  95 three output files.</p>
  96 <ul>
  97 <li>C code to implement a parser for the input grammar.
  98 <li>A header file defining an integer ID for each terminal symbol
  99     (or "token").
 100 <li>An information file that describes the states of the generated parser
 101     automaton.
 102 </ul>
 103 <p>By default, all three of these output files are generated.
 104 The header file is suppressed if the "-m" command-line option is
 105 used and the report file is omitted when "-q" is selected.</p>
 106
 107 <p>The grammar specification file uses a ".y" suffix, by convention.
 108 In the examples used in this document, we'll assume the name of the
 109 grammar file is "gram.y".  A typical use of Lemon would be the
 110 following command:</p>
 111 <pre>
 112    lemon gram.y
 113 </pre>
 114 <p>This command will generate three output files named "gram.c",
 115 "gram.h" and "gram.out".
 116 The first is C code to implement the parser.  The second
 117 is the header file that defines numerical values for all
 118 terminal symbols, and the last is the report that explains
 119 the states used by the parser automaton.</p>
 120
 121 <a id="options"></a>
 122 <h3>3.1 Command Line Options</h3>
 123
 124 <p>The behavior of Lemon can be modified using command-line options.
 125 You can obtain a list of the available command-line options together
 126 with a brief explanation of what each does by typing</p>
 127 <pre>
 128    lemon "-?"
 129 </pre>
 130 <p>As of this writing, the following command-line options are supported:</p>
 131 <ul>
 132 <li><b>-b</b>
 133 Show only the basis for each parser state in the report file.
 134 <li><b>-c</b>
 135 Do not compress the generated action tables.  The parser will be a
 136 little larger and slower, but it will detect syntax errors sooner.
 137 <li><b>-d</b><i>directory</i>
 138 Write all output files into <i>directory</i>.  Normally, output files
 139 are written into the directory that contains the input grammar file.
 140 <li><b>-D<i>name</i></b>
 141 Define C preprocessor macro <i>name</i>.  This macro is usable by
 142 "<tt><a href='#pifdef'>%ifdef</a></tt>",
 143 "<tt><a href='#pifdef'>%ifndef</a></tt>", and
 144 "<tt><a href="#pifdef">%if</a></tt> lines
 145 in the grammar file.
 146 <li><b>-E</b>
 147 Run the "%if" preprocessor step only and print the revised grammar
 148 file.
 149 <li><b>-g</b>
 150 Do not generate a parser.  Instead write the input grammar to standard
 151 output with all comments, actions, and other extraneous text removed.
 152 <li><b>-l</b>
 153 Omit "#line" directives in the generated parser C code.
 154 <li><b>-m</b>
 155 Cause the output C source code to be compatible with the "makeheaders"
 156 program.
 157 <li><b>-p</b>
 158 Display all conflicts that are resolved by
 159 <a href='#precrules'>precedence rules</a>.
 160 <li><b>-q</b>
 161 Suppress generation of the report file.
 162 <li><b>-r</b>
 163 Do not sort or renumber the parser states as part of optimization.
 164 <li><b>-s</b>
 165 Show parser statistics before exiting.
 166 <li><b>-T<i>file</i></b>
 167 Use <i>file</i> as the template for the generated C-code parser implementation.
 168 <li><b>-x</b>
 169 Print the Lemon version number.
 170 </ul>
 171
 172 <a id="interface"></a>
 173 <h3>3.2 The Parser Interface</h3>
 174
 175 <p>Lemon doesn't generate a complete, working program.  It only generates
 176 a few subroutines that implement a parser.  This section describes
 177 the interface to those subroutines.  It is up to the programmer to
 178 call these subroutines in an appropriate way in order to produce a
 179 complete system.</p>
 180
 181 <p>Before a program begins using a Lemon-generated parser, the program
 182 must first create the parser.
 183 A new parser is created as follows:</p>
 184 <pre>
 185    void *pParser = ParseAlloc( malloc );
 186 </pre>
 187 <p>The ParseAlloc() routine allocates and initializes a new parser and
 188 returns a pointer to it.
 189 The actual data structure used to represent a parser is opaque &mdash;
 190 its internal structure is not visible or usable by the calling routine.
 191 For this reason, the ParseAlloc() routine returns a pointer to void
 192 rather than a pointer to some particular structure.
 193 The sole argument to the ParseAlloc() routine is a pointer to the
 194 subroutine used to allocate memory.  Typically this means malloc().</p>
 195
 196 <p>After a program is finished using a parser, it can reclaim all
 197 memory allocated by that parser by calling</p>
 198 <pre>
 199    ParseFree(pParser, free);
 200 </pre>
 201 <p>The first argument is the same pointer returned by ParseAlloc().  The
 202 second argument is a pointer to the function used to release bulk
 203 memory back to the system.</p>
 204
 205 <p>After a parser has been allocated using ParseAlloc(), the programmer
 206 must supply the parser with a sequence of tokens (terminal symbols) to
 207 be parsed.  This is accomplished by calling the following function
 208 once for each token:<p>
 209 <pre>
 210    Parse(pParser, hTokenID, sTokenData, pArg);
 211 </pre>
 212 <p>The first argument to the Parse() routine is the pointer returned by
 213 ParseAlloc().
 214 The second argument is a small positive integer that tells the parser the
 215 type of the next token in the data stream.
 216 There is one token type for each terminal symbol in the grammar.
 217 The gram.h file generated by Lemon contains #define statements that
 218 map symbolic terminal symbol names into appropriate integer values.
 219 A value of 0 for the second argument is a special flag to the
 220 parser to indicate that the end of input has been reached.
 221 The third argument is the value of the given token.  By default,
 222 the type of the third argument is "void*", but the grammar will
 223 usually redefine this type to be some kind of structure.
 224 Typically the second argument will be a broad category of tokens
 225 such as "identifier" or "number" and the third argument will
 226 be the name of the identifier or the value of the number.</p>
 227
 228 <p>The Parse() function may have either three or four arguments,
 229 depending on the grammar.  If the grammar specification file requests
 230 it (via the <tt><a href='#extraarg'>%extra_argument</a></tt> directive),
 231 the Parse() function will have a fourth parameter that can be
 232 of any type chosen by the programmer.  The parser doesn't do anything
 233 with this argument except to pass it through to action routines.
 234 This is a convenient mechanism for passing state information down
 235 to the action routines without having to use global variables.</p>
 236
 237 <p>A typical use of a Lemon parser might look something like the
 238 following:</p>
 239 <pre>
 240     1 ParseTree *ParseFile(const char *zFilename){
 241     2    Tokenizer *pTokenizer;
 242     3    void *pParser;
 243     4    Token sToken;
 244     5    int hTokenId;
 245     6    ParserState sState;
 246     7
 247     8    pTokenizer = TokenizerCreate(zFilename);
 248     9    pParser = ParseAlloc( malloc );
 249    10    InitParserState(&amp;sState);
 250    11    while( GetNextToken(pTokenizer, &amp;hTokenId, &amp;sToken) ){
 251    12       Parse(pParser, hTokenId, sToken, &amp;sState);
 252    13    }
 253    14    Parse(pParser, 0, sToken, &amp;sState);
 254    15    ParseFree(pParser, free );
 255    16    TokenizerFree(pTokenizer);
 256    17    return sState.treeRoot;
 257    18 }
 258 </pre>
 259 <p>This example shows a user-written routine that parses a file of
 260 text and returns a pointer to the parse tree.
 261 (All error-handling code is omitted from this example to keep it
 262 simple.)
 263 We assume the existence of some kind of tokenizer which is created
 264 using TokenizerCreate() on line 8 and deleted by TokenizerFree()
 265 on line 16.  The GetNextToken() function on line 11 retrieves the
 266 next token from the input file and puts its type in the
 267 integer variable hTokenId.  The sToken variable is assumed to be
 268 some kind of structure that contains details about each token,
 269 such as its complete text, what line it occurs on, etc.</p>
 270
 271 <p>This example also assumes the existence of a structure of type
 272 ParserState that holds state information about a particular parse.
 273 An instance of such a structure is created on line 6 and initialized
 274 on line 10.  A pointer to this structure is passed into the Parse()
 275 routine as the optional 4th argument.
 276 The action routine specified by the grammar for the parser can use
 277 the ParserState structure to hold whatever information is useful and
 278 appropriate.  In the example, we note that the treeRoot field of
 279 the ParserState structure is left pointing to the root of the parse
 280 tree.</p>
 281
 282 <p>The core of this example as it relates to Lemon is as follows:</p>
 283 <pre>
 284    ParseFile(){
 285       pParser = ParseAlloc( malloc );
 286       while( GetNextToken(pTokenizer,&amp;hTokenId, &amp;sToken) ){
 287          Parse(pParser, hTokenId, sToken);
 288       }
 289       Parse(pParser, 0, sToken);
 290       ParseFree(pParser, free );
 291    }
 292 </pre>
 293 <p>Basically, what a program has to do to use a Lemon-generated parser
 294 is first create the parser, then send it lots of tokens obtained by
 295 tokenizing an input source.  When the end of input is reached, the
 296 Parse() routine should be called one last time with a token type
 297 of 0.  This step is necessary to inform the parser that the end of
 298 input has been reached.  Finally, we reclaim memory used by the
 299 parser by calling ParseFree().</p>
 300
 301 <p>There is one other interface routine that should be mentioned
 302 before we move on.
 303 The ParseTrace() function can be used to generate debugging output
 304 from the parser.  A prototype for this routine is as follows:</p>
 305 <pre>
 306    ParseTrace(FILE *stream, char *zPrefix);
 307 </pre>
 308 <p>After this routine is called, a short (one-line) message is written
 309 to the designated output stream every time the parser changes states
 310 or calls an action routine.  Each such message is prefaced using
 311 the text given by zPrefix.  This debugging output can be turned off
 312 by calling ParseTrace() again with a first argument of NULL (0).</p>
 313
 314 <a id="onstack"></a>
 315 <h4>3.2.1 Allocating The Parse Object On Stack</h4>
 316
 317 <p>If all calls to the Parse() interface are made from within
 318 <a href="#pcode"><tt>%code</tt> directives</a>, then the parse
 319 object can be allocated from the stack rather than from the heap.
 320 These are the steps:
 321
 322 <ul>
 323 <li> Declare a local variable of type "yyParser"
 324 <li> Initialize the variable using ParseInit()
 325 <li> Pass a pointer to the variable in calls ot Parse()
 326 <li> Deallocate substructure in the parse variable using ParseFinalize().
 327 </ul>
 328
 329 <p>The following code illustrates how this is done:
 330
 331 <pre>
 332    ParseFile(){
 333       yyParser x;
 334       ParseInit( &x );
 335       while( GetNextToken(pTokenizer,&amp;hTokenId, &amp;sToken) ){
 336          Parse(&x, hTokenId, sToken);
 337       }
 338       Parse(&x, 0, sToken);
 339       ParseFinalize( &x );
 340    }
 341 </pre>
 342
 343 <a id="ifsum"></a>
 344 <h4>3.2.2 Interface Summary</h4>
 345
 346 <p>Here is a quick overview of the C-language interface to a
 347 Lemon-generated parser:</p>
 348
 349 <blockquote><pre>
 350 void *ParseAlloc( (void*(*malloc)(size_t) );
 351 void ParseFree(void *pParser, (void(*free)(void*) );
 352 void Parse(void *pParser, int tokenCode, ParseTOKENTYPE token, ...);
 353 void ParseTrace(FILE *stream, char *zPrefix);
 354 </pre></blockquote>
 355
 356 <p>Notes:</p>
 357 <ul>
 358 <li> Use the <a href="#pname"><tt>%name</tt> directive</a> to change
 359 the "Parse" prefix names of the procedures in the interface.
 360 <li> Use the <a href="#token_type"><tt>%token_type</tt> directive</a>
 361 to define the "ParseTOKENTYPE" type.
 362 <li> Use the <a href="#extraarg"><tt>%extra_argument</tt> directive</a>
 363 to specify the type and name of the 4th parameter to the
 364 Parse() function.
 365 </ul>
 366
 367 <a id="yaccdiff"></a>
 368 <h3>3.3 Differences With YACC and BISON</h3>
 369
 370 <p>Programmers who have previously used the yacc or bison parser
 371 generator will notice several important differences between yacc and/or
 372 bison and Lemon.</p>
 373 <ul>
 374 <li>In yacc and bison, the parser calls the tokenizer.  In Lemon,
 375     the tokenizer calls the parser.
 376 <li>Lemon uses no global variables.  Yacc and bison use global variables
 377     to pass information between the tokenizer and parser.
 378 <li>Lemon allows multiple parsers to be running simultaneously.  Yacc
 379     and bison do not.
 380 </ul>
 381 <p>These differences may cause some initial confusion for programmers
 382 with prior yacc and bison experience.
 383 But after years of experience using Lemon, I firmly
 384 believe that the Lemon way of doing things is better.</p>
 385
 386 <p><i>Updated as of 2016-02-16:</i>
 387 The text above was written in the 1990s.
 388 We are told that Bison has lately been enhanced to support the
 389 tokenizer-calls-parser paradigm used by Lemon, eliminating the
 390 need for global variables.</p>
 391
 392 <a id="build"><a>
 393 <h3>3.4 Building The "lemon" or "lemon.exe" Executable</h3>
 394
 395 <p>The "lemon" or "lemon.exe" program is built from a single file
 396 of C-code named
 397 "<a href="https://sqlite.org/src/tool/lemon.c">lemon.c</a>".
 398 The Lemon source code is generic C89 code that uses
 399 no unusual or non-standard libraries.  Any
 400 reasonable C compiler should suffice to compile the lemon program.
 401 A command-line like the following will usually work:</p>
 402
 403 <blockquote><pre>
 404 cc -o lemon lemon.c
 405 </pre></blockquote
 406
 407 <p>On Windows machines with Visual C++ installed, bring up a
 408 "VS20<i>NN</i> x64 Native Tools Command Prompt" window and enter:
 409
 410 <blockquote><pre>
 411 cl lemon.c
 412 </pre></blockquote>
 413
 414 <p>Compiling Lemon really is that simple.
 415 Additional compiler options such as
 416 "-O2" or "-g" or "-Wall" can be added if desired, but they are not
 417 necessary.</p>
 418
 419
 420 <a id="syntax"></a>
 421 <h2>4.0 Input File Syntax</h2>
 422
 423 <p>The main purpose of the grammar specification file for Lemon is
 424 to define the grammar for the parser.  But the input file also
 425 specifies additional information Lemon requires to do its job.
 426 Most of the work in using Lemon is in writing an appropriate
 427 grammar file.</p>
 428
 429 <p>The grammar file for Lemon is, for the most part, a free format.
 430 It does not have sections or divisions like yacc or bison.  Any
 431 declaration can occur at any point in the file.  Lemon ignores
 432 whitespace (except where it is needed to separate tokens), and it
 433 honors the same commenting conventions as C and C++.</p>
 434
 435 <a id="tnt"></a>
 436 <h3>4.1 Terminals and Nonterminals</h3>
 437
 438 <p>A terminal symbol (token) is any string of alphanumeric
 439 and/or underscore characters
 440 that begins with an uppercase letter.
 441 A terminal can contain lowercase letters after the first character,
 442 but the usual convention is to make terminals all uppercase.
 443 A nonterminal, on the other hand, is any string of alphanumeric
 444 and underscore characters than begins with a lowercase letter.
 445 Again, the usual convention is to make nonterminals use all lowercase
 446 letters.</p>
 447
 448 <p>In Lemon, terminal and nonterminal symbols do not need to
 449 be declared or identified in a separate section of the grammar file.
 450 Lemon is able to generate a list of all terminals and nonterminals
 451 by examining the grammar rules, and it can always distinguish a
 452 terminal from a nonterminal by checking the case of the first
 453 character of the name.</p>
 454
 455 <p>Yacc and bison allow terminal symbols to have either alphanumeric
 456 names or to be individual characters included in single quotes, like
 457 this: ')' or '$'.  Lemon does not allow this alternative form for
 458 terminal symbols.  With Lemon, all symbols, terminals and nonterminals,
 459 must have alphanumeric names.</p>
 460
 461 <a id="rules"></a>
 462 <h3>4.2 Grammar Rules</h3>
 463
 464 <p>The main component of a Lemon grammar file is a sequence of grammar
 465 rules.
 466 Each grammar rule consists of a nonterminal symbol followed by
 467 the special symbol "::=" and then a list of terminals and/or nonterminals.
 468 The rule is terminated by a period.
 469 The list of terminals and nonterminals on the right-hand side of the
 470 rule can be empty.
 471 Rules can occur in any order, except that the left-hand side of the
 472 first rule is assumed to be the start symbol for the grammar (unless
 473 specified otherwise using the <tt><a href='#start_symbol'>%start_symbol</a></tt>
 474 directive described below.)
 475 A typical sequence of grammar rules might look something like this:</p>
 476 <pre>
 477   expr ::= expr PLUS expr.
 478   expr ::= expr TIMES expr.
 479   expr ::= LPAREN expr RPAREN.
 480   expr ::= VALUE.
 481 </pre>
 482
 483 <p>There is one non-terminal in this example, "expr", and five
 484 terminal symbols or tokens: "PLUS", "TIMES", "LPAREN",
 485 "RPAREN" and "VALUE".</p>
 486
 487 <p>Like yacc and bison, Lemon allows the grammar to specify a block
 488 of C code that will be executed whenever a grammar rule is reduced
 489 by the parser.
 490 In Lemon, this action is specified by putting the C code (contained
 491 within curly braces <tt>{...}</tt>) immediately after the
 492 period that closes the rule.
 493 For example:</p>
 494 <pre>
 495   expr ::= expr PLUS expr.   { printf("Doing an addition...\n"); }
 496 </pre>
 497
 498 <p>In order to be useful, grammar actions must normally be linked to
 499 their associated grammar rules.
 500 In yacc and bison, this is accomplished by embedding a "$$" in the
 501 action to stand for the value of the left-hand side of the rule and
 502 symbols "$1", "$2", and so forth to stand for the value of
 503 the terminal or nonterminal at position 1, 2 and so forth on the
 504 right-hand side of the rule.
 505 This idea is very powerful, but it is also very error-prone.  The
 506 single most common source of errors in a yacc or bison grammar is
 507 to miscount the number of symbols on the right-hand side of a grammar
 508 rule and say "$7" when you really mean "$8".</p>
 509
 510 <p>Lemon avoids the need to count grammar symbols by assigning symbolic
 511 names to each symbol in a grammar rule and then using those symbolic
 512 names in the action.
 513 In yacc or bison, one would write this:</p>
 514 <pre>
 515   expr -&gt; expr PLUS expr  { $$ = $1 + $3; };
 516 </pre>
 517 <p>But in Lemon, the same rule becomes the following:</p>
 518 <pre>
 519   expr(A) ::= expr(B) PLUS expr(C).  { A = B+C; }
 520 </pre>
 521 <p>In the Lemon rule, any symbol in parentheses after a grammar rule
 522 symbol becomes a place holder for that symbol in the grammar rule.
 523 This place holder can then be used in the associated C action to
 524 stand for the value of that symbol.</p>
 525
 526 <p>The Lemon notation for linking a grammar rule with its reduce
 527 action is superior to yacc/bison on several counts.
 528 First, as mentioned above, the Lemon method avoids the need to
 529 count grammar symbols.
 530 Secondly, if a terminal or nonterminal in a Lemon grammar rule
 531 includes a linking symbol in parentheses but that linking symbol
 532 is not actually used in the reduce action, then an error message
 533 is generated.
 534 For example, the rule</p>
 535 <pre>
 536   expr(A) ::= expr(B) PLUS expr(C).  { A = B; }
 537 </pre>
 538 <p>will generate an error because the linking symbol "C" is used
 539 in the grammar rule but not in the reduce action.</p>
 540
 541 <p>The Lemon notation for linking grammar rules to reduce actions
 542 also facilitates the use of destructors for reclaiming memory
 543 allocated by the values of terminals and nonterminals on the
 544 right-hand side of a rule.</p>
 545
 546 <a id='precrules'></a>
 547 <h3>4.3 Precedence Rules</h3>
 548
 549 <p>Lemon resolves parsing ambiguities in exactly the same way as
 550 yacc and bison.  A shift-reduce conflict is resolved in favor
 551 of the shift, and a reduce-reduce conflict is resolved by reducing
 552 whichever rule comes first in the grammar file.</p>
 553
 554 <p>Just like in
 555 yacc and bison, Lemon allows a measure of control
 556 over the resolution of parsing conflicts using precedence rules.
 557 A precedence value can be assigned to any terminal symbol
 558 using the
 559 <tt><a href='#pleft'>%left</a></tt>,
 560 <tt><a href='#pright'>%right</a></tt> or
 561 <tt><a href='#pnonassoc'>%nonassoc</a></tt> directives.  Terminal symbols
 562 mentioned in earlier directives have a lower precedence than
 563 terminal symbols mentioned in later directives.  For example:</p>
 564
 565 <pre>
 566    %left AND.
 567    %left OR.
 568    %nonassoc EQ NE GT GE LT LE.
 569    %left PLUS MINUS.
 570    %left TIMES DIVIDE MOD.
 571    %right EXP NOT.
 572 </pre>
 573
 574 <p>In the preceding sequence of directives, the AND operator is
 575 defined to have the lowest precedence.  The OR operator is one
 576 precedence level higher.  And so forth.  Hence, the grammar would
 577 attempt to group the ambiguous expression</p>
 578 <pre>
 579      a AND b OR c
 580 </pre>
 581 <p>like this</p>
 582 <pre>
 583      a AND (b OR c).
 584 </pre>
 585 <p>The associativity (left, right or nonassoc) is used to determine
 586 the grouping when the precedence is the same.  AND is left-associative
 587 in our example, so</p>
 588 <pre>
 589      a AND b AND c
 590 </pre>
 591 <p>is parsed like this</p>
 592 <pre>
 593      (a AND b) AND c.
 594 </pre>
 595 <p>The EXP operator is right-associative, though, so</p>
 596 <pre>
 597      a EXP b EXP c
 598 </pre>
 599 <p>is parsed like this</p>
 600 <pre>
 601      a EXP (b EXP c).
 602 </pre>
 603 <p>The nonassoc precedence is used for non-associative operators.
 604 So</p>
 605 <pre>
 606      a EQ b EQ c
 607 </pre>
 608 <p>is an error.</p>
 609
 610 <p>The precedence of non-terminals is transferred to rules as follows:
 611 The precedence of a grammar rule is equal to the precedence of the
 612 left-most terminal symbol in the rule for which a precedence is
 613 defined.  This is normally what you want, but in those cases where
 614 you want the precedence of a grammar rule to be something different,
 615 you can specify an alternative precedence symbol by putting the
 616 symbol in square braces after the period at the end of the rule and
 617 before any C-code.  For example:</p>
 618
 619 <pre>
 620    expr = MINUS expr.  [NOT]
 621 </pre>
 622
 623 <p>This rule has a precedence equal to that of the NOT symbol, not the
 624 MINUS symbol as would have been the case by default.</p>
 625
 626 <p>With the knowledge of how precedence is assigned to terminal
 627 symbols and individual
 628 grammar rules, we can now explain precisely how parsing conflicts
 629 are resolved in Lemon.  Shift-reduce conflicts are resolved
 630 as follows:</p>
 631 <ul>
 632 <li> If either the token to be shifted or the rule to be reduced
 633      lacks precedence information, then resolve in favor of the
 634      shift, but report a parsing conflict.
 635 <li> If the precedence of the token to be shifted is greater than
 636      the precedence of the rule to reduce, then resolve in favor
 637      of the shift.  No parsing conflict is reported.
 638 <li> If the precedence of the token to be shifted is less than the
 639      precedence of the rule to reduce, then resolve in favor of the
 640      reduce action.  No parsing conflict is reported.
 641 <li> If the precedences are the same and the shift token is
 642      right-associative, then resolve in favor of the shift.
 643      No parsing conflict is reported.
 644 <li> If the precedences are the same and the shift token is
 645      left-associative, then resolve in favor of the reduce.
 646      No parsing conflict is reported.
 647 <li> Otherwise, resolve the conflict by doing the shift, and
 648      report a parsing conflict.
 649 </ul>
 650 <p>Reduce-reduce conflicts are resolved this way:</p>
 651 <ul>
 652 <li> If either reduce rule
 653      lacks precedence information, then resolve in favor of the
 654      rule that appears first in the grammar, and report a parsing
 655      conflict.
 656 <li> If both rules have precedence and the precedence is different,
 657      then resolve the dispute in favor of the rule with the highest
 658      precedence, and do not report a conflict.
 659 <li> Otherwise, resolve the conflict by reducing by the rule that
 660      appears first in the grammar, and report a parsing conflict.
 661 </ul>
 662
 663 <a id="special"></a>
 664 <h3>4.4 Special Directives</h3>
 665
 666 <p>The input grammar to Lemon consists of grammar rules and special
 667 directives.  We've described all the grammar rules, so now we'll
 668 talk about the special directives.</p>
 669
 670 <p>Directives in Lemon can occur in any order.  You can put them before
 671 the grammar rules, or after the grammar rules, or in the midst of the
 672 grammar rules.  It doesn't matter.  The relative order of
 673 directives used to assign precedence to terminals is important, but
 674 other than that, the order of directives in Lemon is arbitrary.</p>
 675
 676 <p>Lemon supports the following special directives:</p>
 677 <ul>
 678 <li><tt><a href='#pcode'>%code</a></tt>
 679 <li><tt><a href='#default_destructor'>%default_destructor</a></tt>
 680 <li><tt><a href='#default_type'>%default_type</a></tt>
 681 <li><tt><a href='#destructor'>%destructor</a></tt>
 682 <li><tt><a href='#pifdef'>%else</a></tt>
 683 <li><tt><a href='#pifdef'>%endif</a></tt>
 684 <li><tt><a href='#extraarg'>%extra_argument</a></tt>
 685 <li><tt><a href='#pfallback'>%fallback</a></tt>
 686 <li><tt><a href='#pifdef'>%if</a></tt>
 687 <li><tt><a href='#pifdef'>%ifdef</a></tt>
 688 <li><tt><a href='#pifdef'>%ifndef</a></tt>
 689 <li><tt><a href='#pinclude'>%include</a></tt>
 690 <li><tt><a href='#pleft'>%left</a></tt>
 691 <li><tt><a href='#pname'>%name</a></tt>
 692 <li><tt><a href='#pnonassoc'>%nonassoc</a></tt>
 693 <li><tt><a href='#parse_accept'>%parse_accept</a></tt>
 694 <li><tt><a href='#parse_failure'>%parse_failure</a></tt>
 695 <li><tt><a href='#pright'>%right</a></tt>
 696 <li><tt><a href='#stack_overflow'>%stack_overflow</a></tt>
 697 <li><tt><a href='#stack_size'>%stack_size</a></tt>
 698 <li><tt><a href='#start_symbol'>%start_symbol</a></tt>
 699 <li><tt><a href='#syntax_error'>%syntax_error</a></tt>
 700 <li><tt><a href='#token'>%token</a></tt>
 701 <li><tt><a href='#token_class'>%token_class</a></tt>
 702 <li><tt><a href='#token_destructor'>%token_destructor</a></tt>
 703 <li><tt><a href='#token_prefix'>%token_prefix</a></tt>
 704 <li><tt><a href='#token_type'>%token_type</a></tt>
 705 <li><tt><a href='#ptype'>%type</a></tt>
 706 <li><tt><a href='#pwildcard'>%wildcard</a></tt>
 707 </ul>
 708 <p>Each of these directives will be described separately in the
 709 following sections:</p>
 710
 711 <a id='pcode'></a>
 712 <h4>4.4.1 The <tt>%code</tt> directive</h4>
 713
 714 <p>The <tt>%code</tt> directive is used to specify additional C code that
 715 is added to the end of the main output file.  This is similar to
 716 the <tt><a href='#pinclude'>%include</a></tt> directive except that
 717 <tt>%include</tt> is inserted at the beginning of the main output file.</p>
 718
 719 <p><tt>%code</tt> is typically used to include some action routines or perhaps
 720 a tokenizer or even the "main()" function
 721 as part of the output file.</p>
 722
 723 <p>There can be multiple <tt>%code</tt> directives.  The arguments of
 724 all <tt>%code</tt> directives are concatenated.</p>
 725
 726 <a id='default_destructor'></a>
 727 <h4>4.4.2 The <tt>%default_destructor</tt> directive</h4>
 728
 729 <p>The <tt>%default_destructor</tt> directive specifies a destructor to
 730 use for non-terminals that do not have their own destructor
 731 specified by a separate <tt>%destructor</tt> directive.  See the documentation
 732 on the <tt><a href='#destructor'>%destructor</a></tt> directive below for
 733 additional information.</p>
 734
 735 <p>In some grammars, many different non-terminal symbols have the
 736 same data type and hence the same destructor.  This directive is
 737 a convenient way to specify the same destructor for all those
 738 non-terminals using a single statement.</p>
 739
 740 <a id='default_type'></a>
 741 <h4>4.4.3 The <tt>%default_type</tt> directive</h4>
 742
 743 <p>The <tt>%default_type</tt> directive specifies the data type of non-terminal
 744 symbols that do not have their own data type defined using a separate
 745 <tt><a href='#ptype'>%type</a></tt> directive.</p>
 746
 747 <a id='destructor'></a>
 748 <h4>4.4.4 The <tt>%destructor</tt> directive</h4>
 749
 750 <p>The <tt>%destructor</tt> directive is used to specify a destructor for
 751 a non-terminal symbol.
 752 (See also the <tt><a href='#token_destructor'>%token_destructor</a></tt>
 753 directive which is used to specify a destructor for terminal symbols.)</p>
 754
 755 <p>A non-terminal's destructor is called to dispose of the
 756 non-terminal's value whenever the non-terminal is popped from
 757 the stack.  This includes all of the following circumstances:</p>
 758 <ul>
 759 <li> When a rule reduces and the value of a non-terminal on
 760      the right-hand side is not linked to C code.
 761 <li> When the stack is popped during error processing.
 762 <li> When the ParseFree() function runs.
 763 </ul>
 764 <p>The destructor can do whatever it wants with the value of
 765 the non-terminal, but its design is to deallocate memory
 766 or other resources held by that non-terminal.</p>
 767
 768 <p>Consider an example:</p>
 769 <pre>
 770    %type nt {void*}
 771    %destructor nt { free($$); }
 772    nt(A) ::= ID NUM.   { A = malloc( 100 ); }
 773 </pre>
 774 <p>This example is a bit contrived, but it serves to illustrate how
 775 destructors work.  The example shows a non-terminal named
 776 "nt" that holds values of type "void*".  When the rule for
 777 an "nt" reduces, it sets the value of the non-terminal to
 778 space obtained from malloc().  Later, when the nt non-terminal
 779 is popped from the stack, the destructor will fire and call
 780 free() on this malloced space, thus avoiding a memory leak.
 781 (Note that the symbol "$$" in the destructor code is replaced
 782 by the value of the non-terminal.)</p>
 783
 784 <p>It is important to note that the value of a non-terminal is passed
 785 to the destructor whenever the non-terminal is removed from the
 786 stack, unless the non-terminal is used in a C-code action.  If
 787 the non-terminal is used by C-code, then it is assumed that the
 788 C-code will take care of destroying it.
 789 More commonly, the value is used to build some
 790 larger structure, and we don't want to destroy it, which is why
 791 the destructor is not called in this circumstance.</p>
 792
 793 <p>Destructors help avoid memory leaks by automatically freeing
 794 allocated objects when they go out of scope.
 795 To do the same using yacc or bison is much more difficult.</p>
 796
 797 <a id='extraarg'></a>
 798 <h4>4.4.5 The <tt>%extra_argument</tt> directive</h4>
 799
 800 <p>The <tt>%extra_argument</tt> directive instructs Lemon to add a 4th parameter
 801 to the parameter list of the Parse() function it generates.  Lemon
 802 doesn't do anything itself with this extra argument, but it does
 803 make the argument available to C-code action routines, destructors,
 804 and so forth.  For example, if the grammar file contains:</p>
 805
 806 <pre>
 807     %extra_argument { MyStruct *pAbc }
 808 </pre>
 809
 810 <p>Then the Parse() function generated will have an 4th parameter
 811 of type "MyStruct*" and all action routines will have access to
 812 a variable named "pAbc" that is the value of the 4th parameter
 813 in the most recent call to Parse().</p>
 814
 815 <p>The <tt>%extra_context</tt> directive works the same except that it
 816 is passed in on the ParseAlloc() or ParseInit() routines instead of
 817 on Parse().</p>
 818
 819 <a id='extractx'></a>
 820 <h4>4.4.6 The <tt>%extra_context</tt> directive</h4>
 821
 822 <p>The <tt>%extra_context</tt> directive instructs Lemon to add a 2nd parameter
 823 to the parameter list of the ParseAlloc() and ParseInit() functions.  Lemon
 824 doesn't do anything itself with these extra argument, but it does
 825 store the value make it available to C-code action routines, destructors,
 826 and so forth.  For example, if the grammar file contains:</p>
 827
 828 <pre>
 829     %extra_context { MyStruct *pAbc }
 830 </pre>
 831
 832 <p>Then the ParseAlloc() and ParseInit() functions will have an 2nd parameter
 833 of type "MyStruct*" and all action routines will have access to
 834 a variable named "pAbc" that is the value of that 2nd parameter.</p>
 835
 836 <p>The <tt>%extra_argument</tt> directive works the same except that it
 837 is passed in on the Parse() routine instead of on ParseAlloc()/ParseInit().</p>
 838
 839 <a id='pfallback'></a>
 840 <h4>4.4.7 The <tt>%fallback</tt> directive</h4>
 841
 842 <p>The <tt>%fallback</tt> directive specifies an alternative meaning for one
 843 or more tokens.  The alternative meaning is tried if the original token
 844 would have generated a syntax error.</p>
 845
 846 <p>The <tt>%fallback</tt> directive was added to support robust parsing of SQL
 847 syntax in <a href='https://www.sqlite.org/'>SQLite</a>.
 848 The SQL language contains a large assortment of keywords, each of which
 849 appears as a different token to the language parser.  SQL contains so
 850 many keywords that it can be difficult for programmers to keep up with
 851 them all.  Programmers will, therefore, sometimes mistakenly use an
 852 obscure language keyword for an identifier.  The <tt>%fallback</tt> directive
 853 provides a mechanism to tell the parser:  "If you are unable to parse
 854 this keyword, try treating it as an identifier instead."</p>
 855
 856 <p>The syntax of <tt>%fallback</tt> is as follows:</p>
 857
 858 <blockquote>
 859 <tt>%fallback</tt> <i>ID</i> <i>TOKEN...</i> <b>.</b>
 860 </blockquote></p>
 861
 862 <p>In words, the <tt>%fallback</tt> directive is followed by a list of token
 863 names terminated by a period.
 864 The first token name is the fallback token &mdash; the
 865 token to which all the other tokens fall back to.  The second and subsequent
 866 arguments are tokens which fall back to the token identified by the first
 867 argument.</p>
 868
 869 <a id='pifdef'></a>
 870 <h4>4.4.8 The <tt>%if</tt> directive and its friends</h4>
 871
 872 <p>The <tt>%if</tt>, <tt>%ifdef</tt>, <tt>%ifndef</tt>, <tt>%else</tt>,
 873 and <tt>%endif</tt> directives
 874 are similar to #if, #ifdef, #ifndef, #else, and #endif in the C-preprocessor,
 875 just not as general.
 876 Each of these directives must begin at the left margin.  No whitespace
 877 is allowed between the "%" and the directive name.</p>
 878
 879 <p>Grammar text in between "<tt>%ifdef MACRO</tt>" and the next nested
 880 "<tt>%endif</tt>" is
 881 ignored unless the "-DMACRO" command-line option is used.  Grammar text
 882 betwen "<tt>%ifndef MACRO</tt>" and the next nested "<tt>%endif</tt>" is
 883 included except when the "-DMACRO" command-line option is used.<p>
 884
 885 <p>The text in between "<tt>%if</tt> <i>CONDITIONAL</i>" and its
 886 corresponding <tt>%endif</tt> is included only if <i>CONDITIONAL</i>
 887 is true.  The CONDITION is one or more macro names, optionally connected
 888 using the "||" and "&amp;&amp;" binary operators, the "!" unary operator,
 889 and grouped using balanced parentheses.  Each term is true if the
 890 corresponding macro exists, and false if it does not exist.</p>
 891
 892 <p>An optional "<tt>%else</tt>" directive can occur anywhere in between a
 893 <tt>%ifdef</tt>, <tt>%ifndef</tt>, or <tt>%if</tt> directive and
 894 its corresponding <tt>%endif</tt>.</p>
 895
 896 <p>Note that the argument to <tt>%ifdef</tt> and <tt>%ifndef</tt> is
 897 intended to be a single preprocessor symbol name, not a general expression.
 898 Use the "<tt>%if</tt>" directive for general expressions.</p>
 899
 900 <a id='pinclude'></a>
 901 <h4>4.4.9 The <tt>%include</tt> directive</h4>
 902
 903 <p>The <tt>%include</tt> directive specifies C code that is included at the
 904 top of the generated parser.  You can include any text you want &mdash;
 905 the Lemon parser generator copies it blindly.  If you have multiple
 906 <tt>%include</tt> directives in your grammar file, their values are concatenated
 907 so that all <tt>%include</tt> code ultimately appears near the top of the
 908 generated parser, in the same order as it appeared in the grammar.</p>
 909
 910 <p>The <tt>%include</tt> directive is very handy for getting some extra #include
 911 preprocessor statements at the beginning of the generated parser.
 912 For example:</p>
 913
 914 <pre>
 915    %include {#include &lt;unistd.h&gt;}
 916 </pre>
 917
 918 <p>This might be needed, for example, if some of the C actions in the
 919 grammar call functions that are prototyped in unistd.h.</p>
 920
 921 <p>Use the <tt><a href="#pcode">%code</a></tt> directive to add code to
 922 the end of the generated parser.</p>
 923
 924 <a id='pleft'></a>
 925 <h4>4.4.10 The <tt>%left</tt> directive</h4>
 926
 927 The <tt>%left</tt> directive is used (along with the
 928 <tt><a href='#pright'>%right</a></tt> and
 929 <tt><a href='#pnonassoc'>%nonassoc</a></tt> directives) to declare
 930 precedences of terminal symbols.
 931 Every terminal symbol whose name appears after
 932 a <tt>%left</tt> directive but before the next period (".") is
 933 given the same left-associative precedence value.  Subsequent
 934 <tt>%left</tt> directives have higher precedence.  For example:</p>
 935
 936 <pre>
 937    %left AND.
 938    %left OR.
 939    %nonassoc EQ NE GT GE LT LE.
 940    %left PLUS MINUS.
 941    %left TIMES DIVIDE MOD.
 942    %right EXP NOT.
 943 </pre>
 944
 945 <p>Note the period that terminates each <tt>%left</tt>,
 946 <tt>%right</tt> or <tt>%nonassoc</tt>
 947 directive.</p>
 948
 949 <p>LALR(1) grammars can get into a situation where they require
 950 a large amount of stack space if you make heavy use or right-associative
 951 operators.  For this reason, it is recommended that you use <tt>%left</tt>
 952 rather than <tt>%right</tt> whenever possible.</p>
 953
 954 <a id='pname'></a>
 955 <h4>4.4.11 The <tt>%name</tt> directive</h4>
 956
 957 <p>By default, the functions generated by Lemon all begin with the
 958 five-character string "Parse".  You can change this string to something
 959 different using the <tt>%name</tt> directive.  For instance:</p>
 960
 961 <pre>
 962    %name Abcde
 963 </pre>
 964
 965 <p>Putting this directive in the grammar file will cause Lemon to generate
 966 functions named</p>
 967 <ul>
 968 <li> AbcdeAlloc(),
 969 <li> AbcdeFree(),
 970 <li> AbcdeTrace(), and
 971 <li> Abcde().
 972 </ul>
 973 </p>The <tt>%name</tt> directive allows you to generate two or more different
 974 parsers and link them all into the same executable.</p>
 975
 976 <a id='pnonassoc'></a>
 977 <h4>4.4.12 The <tt>%nonassoc</tt> directive</h4>
 978
 979 <p>This directive is used to assign non-associative precedence to
 980 one or more terminal symbols.  See the section on
 981 <a href='#precrules'>precedence rules</a>
 982 or on the <tt><a href='#pleft'>%left</a></tt> directive
 983 for additional information.</p>
 984
 985 <a id='parse_accept'></a>
 986 <h4>4.4.13 The <tt>%parse_accept</tt> directive</h4>
 987
 988 <p>The <tt>%parse_accept</tt> directive specifies a block of C code that is
 989 executed whenever the parser accepts its input string.  To "accept"
 990 an input string means that the parser was able to process all tokens
 991 without error.</p>
 992
 993 <p>For example:</p>
 994
 995 <pre>
 996    %parse_accept {
 997       printf("parsing complete!\n");
 998    }
 999 </pre>
1000
1001 <a id='parse_failure'></a>
1002 <h4>4.4.14 The <tt>%parse_failure</tt> directive</h4>
1003
1004 <p>The <tt>%parse_failure</tt> directive specifies a block of C code that
1005 is executed whenever the parser fails complete.  This code is not
1006 executed until the parser has tried and failed to resolve an input
1007 error using is usual error recovery strategy.  The routine is
1008 only invoked when parsing is unable to continue.</p>
1009
1010 <pre>
1011    %parse_failure {
1012      fprintf(stderr,"Giving up.  Parser is hopelessly lost...\n");
1013    }
1014 </pre>
1015
1016 <a id='pright'></a>
1017 <h4>4.4.15 The <tt>%right</tt> directive</h4>
1018
1019 <p>This directive is used to assign right-associative precedence to
1020 one or more terminal symbols.  See the section on
1021 <a href='#precrules'>precedence rules</a>
1022 or on the <a href='#pleft'>%left</a> directive for additional information.</p>
1023
1024 <a id='stack_overflow'></a>
1025 <h4>4.4.16 The <tt>%stack_overflow</tt> directive</h4>
1026
1027 <p>The <tt>%stack_overflow</tt> directive specifies a block of C code that
1028 is executed if the parser's internal stack ever overflows.  Typically
1029 this just prints an error message.  After a stack overflow, the parser
1030 will be unable to continue and must be reset.</p>
1031
1032 <pre>
1033    %stack_overflow {
1034      fprintf(stderr,"Giving up.  Parser stack overflow\n");
1035    }
1036 </pre>
1037
1038 <p>You can help prevent parser stack overflows by avoiding the use
1039 of right recursion and right-precedence operators in your grammar.
1040 Use left recursion and and left-precedence operators instead to
1041 encourage rules to reduce sooner and keep the stack size down.
1042 For example, do rules like this:</p>
1043 <pre>
1044    list ::= list element.      // left-recursion.  Good!
1045    list ::= .
1046 </pre>
1047 <p>Not like this:</p>
1048 <pre>
1049    list ::= element list.      // right-recursion.  Bad!
1050    list ::= .
1051 </pre>
1052
1053 <a id='stack_size'></a>
1054 <h4>4.4.17 The <tt>%stack_size</tt> directive</h4>
1055
1056 <p>If stack overflow is a problem and you can't resolve the trouble
1057 by using left-recursion, then you might want to increase the size
1058 of the parser's stack using this directive.  Put an positive integer
1059 after the <tt>%stack_size</tt> directive and Lemon will generate a parse
1060 with a stack of the requested size.  The default value is 100.</p>
1061
1062 <pre>
1063    %stack_size 2000
1064 </pre>
1065
1066 <a id='start_symbol'></a>
1067 <h4>4.4.18 The <tt>%start_symbol</tt> directive</h4>
1068
1069 <p>By default, the start symbol for the grammar that Lemon generates
1070 is the first non-terminal that appears in the grammar file.  But you
1071 can choose a different start symbol using the
1072 <tt>%start_symbol</tt> directive.</p>
1073
1074 <pre>
1075    %start_symbol  prog
1076 </pre>
1077
1078 <a id='syntax_error'></a>
1079 <h4>4.4.19 The <tt>%syntax_error</tt> directive</h4>
1080
1081 <p>See <a href='#errors'>Error Processing</a>.</p>
1082
1083 <a id='token'></a>
1084 <h4>4.4.20 The <tt>%token</tt> directive</h4>
1085
1086 <p>Tokens are normally created automatically, the first time they are used.
1087 Any identifier that begins with an upper-case letter is a token.
1088
1089 <p>Sometimes it is useful to declare tokens in advance, however.  The
1090 integer values assigned to each token determined by the order in which
1091 the tokens are seen.  So by declaring tokens in advance, it is possible to
1092 cause some tokens to have low-numbered values, which might be desirable in
1093 some grammers, or to have sequential values assigned to a sequence of
1094 related tokens.  For this reason, the %token directive is provided to
1095 declare tokens in advance.  The syntax is as follows:
1096
1097 <blockquote>
1098 <tt>%token</tt> <i>TOKEN</i> <i>TOKEN...</i> <b>.</b>
1099 </blockquote></p>
1100
1101 <p>The %token directive is followed by zero or more token symbols and
1102 terminated by a single ".".  Each token named is created if it does not
1103 already exist.  Tokens are created in order.
1104
1105
1106 <a id='token_class'></a>
1107 <h4>4.4.21 The <tt>%token_class</tt> directive</h4>
1108
1109 <p>Undocumented.  Appears to be related to the MULTITERMINAL concept.
1110 <a href='http://sqlite.org/src/fdiff?v1=796930d5fc2036c7&v2=624b24c5dc048e09&sbs=0'>Implementation</a>.</p>
1111
1112 <a id='token_destructor'></a>
1113 <h4>4.4.22 The <tt>%token_destructor</tt> directive</h4>
1114
1115 <p>The <tt>%destructor</tt> directive assigns a destructor to a non-terminal
1116 symbol.  (See the description of the
1117 <tt><a href='%destructor'>%destructor</a></tt> directive above.)
1118 The <tt>%token_destructor</tt> directive does the same thing
1119 for all terminal symbols.</p>
1120
1121 <p>Unlike non-terminal symbols, which may each have a different data type
1122 for their values, terminals all use the same data type (defined by
1123 the <tt><a href='#token_type'>%token_type</a></tt> directive)
1124 and so they use a common destructor.
1125 Other than that, the token destructor works just like the non-terminal
1126 destructors.</p>
1127
1128 <a id='token_prefix'></a>
1129 <h4>4.4.23 The <tt>%token_prefix</tt> directive</h4>
1130
1131 <p>Lemon generates #defines that assign small integer constants
1132 to each terminal symbol in the grammar.  If desired, Lemon will
1133 add a prefix specified by this directive
1134 to each of the #defines it generates.</p>
1135
1136 <p>So if the default output of Lemon looked like this:</p>
1137 <pre>
1138     #define AND              1
1139     #define MINUS            2
1140     #define OR               3
1141     #define PLUS             4
1142 </pre>
1143 <p>You can insert a statement into the grammar like this:</p>
1144 <pre>
1145     %token_prefix    TOKEN_
1146 </pre>
1147 <p>to cause Lemon to produce these symbols instead:</p>
1148 <pre>
1149     #define TOKEN_AND        1
1150     #define TOKEN_MINUS      2
1151     #define TOKEN_OR         3
1152     #define TOKEN_PLUS       4
1153 </pre>
1154
1155 <a id='token_type'></a><a id='ptype'></a>
1156 <h4>4.4.24 The <tt>%token_type</tt> and <tt>%type</tt> directives</h4>
1157
1158 <p>These directives are used to specify the data types for values
1159 on the parser's stack associated with terminal and non-terminal
1160 symbols.  The values of all terminal symbols must be of the same
1161 type.  This turns out to be the same data type as the 3rd parameter
1162 to the Parse() function generated by Lemon.  Typically, you will
1163 make the value of a terminal symbol be a pointer to some kind of
1164 token structure.  Like this:</p>
1165
1166 <pre>
1167    %token_type    {Token*}
1168 </pre>
1169
1170 <p>If the data type of terminals is not specified, the default value
1171 is "void*".</p>
1172
1173 <p>Non-terminal symbols can each have their own data types.  Typically
1174 the data type of a non-terminal is a pointer to the root of a parse tree
1175 structure that contains all information about that non-terminal.
1176 For example:</p>
1177
1178 <pre>
1179    %type   expr  {Expr*}
1180 </pre>
1181
1182 <p>Each entry on the parser's stack is actually a union containing
1183 instances of all data types for every non-terminal and terminal symbol.
1184 Lemon will automatically use the correct element of this union depending
1185 on what the corresponding non-terminal or terminal symbol is.  But
1186 the grammar designer should keep in mind that the size of the union
1187 will be the size of its largest element.  So if you have a single
1188 non-terminal whose data type requires 1K of storage, then your 100
1189 entry parser stack will require 100K of heap space.  If you are willing
1190 and able to pay that price, fine.  You just need to know.</p>
1191
1192 <a id='pwildcard'></a>
1193 <h4>4.4.25 The <tt>%wildcard</tt> directive</h4>
1194
1195 <p>The <tt>%wildcard</tt> directive is followed by a single token name and a
1196 period.  This directive specifies that the identified token should
1197 match any input token.</p>
1198
1199 <p>When the generated parser has the choice of matching an input against
1200 the wildcard token and some other token, the other token is always used.
1201 The wildcard token is only matched if there are no alternatives.</p>
1202
1203 <a id='errors'></a>
1204 <h2>5.0 Error Processing</h2>
1205
1206 <p>After extensive experimentation over several years, it has been
1207 discovered that the error recovery strategy used by yacc is about
1208 as good as it gets.  And so that is what Lemon uses.</p>
1209
1210 <p>When a Lemon-generated parser encounters a syntax error, it
1211 first invokes the code specified by the <tt>%syntax_error</tt> directive, if
1212 any.  It then enters its error recovery strategy.  The error recovery
1213 strategy is to begin popping the parsers stack until it enters a
1214 state where it is permitted to shift a special non-terminal symbol
1215 named "error".  It then shifts this non-terminal and continues
1216 parsing.  The <tt>%syntax_error</tt> routine will not be called again
1217 until at least three new tokens have been successfully shifted.</p>
1218
1219 <p>If the parser pops its stack until the stack is empty, and it still
1220 is unable to shift the error symbol, then the
1221 <tt><a href='#parse_failure'>%parse_failure</a></tt> routine
1222 is invoked and the parser resets itself to its start state, ready
1223 to begin parsing a new file.  This is what will happen at the very
1224 first syntax error, of course, if there are no instances of the
1225 "error" non-terminal in your grammar.</p>
1226
1227 <a id='history'></a>
1228 <h2>6.0 History of Lemon</h2>
1229
1230 <p>Lemon was originally written by Richard Hipp sometime in the late
1231 1980s on a Sun4 Workstation using K&amp;R C.
1232 There was a companion LL(1) parser generator program named "Lime", the
1233 source code to which as been lost.</p>
1234
1235 <p>The lemon.c source file was originally many separate files that were
1236 compiled together to generate the "lemon" executable.  Sometime in the
1237 1990s, the individual source code files were combined together into
1238 the current single large "lemon.c" source file.  You can still see traces
1239 of original filenames in the code.</p>
1240
1241 <p>Since 2001, Lemon has been part of the
1242 <a href="https://sqlite.org/">SQLite project</a> and the source code
1243 to Lemon has been managed as a part of the
1244 <a href="https://sqlite.org/src">SQLite source tree</a> in the following
1245 files:</p>
1246
1247 <ul>
1248 <li> <a href="https://sqlite.org/src/file/tool/lemon.c">tool/lemon.c</a>
1249 <li> <a href="https://sqlite.org/src/file/tool/lempar.c">tool/lempar.c</a>
1250 <li> <a href="https://sqlite.org/src/file/doc/lemon.html">doc/lemon.html</a>
1251 </ul>
1252
1253 <a id="copyright"></a>
1254 <h2>7.0 Copyright</h2>
1255
1256 <p>All of the source code to Lemon, including the template parser file
1257 "lempar.c" and this documentation file ("lemon.html") are in the public
1258 domain.  You can use the code for any purpose and without attribution.</p>
1259
1260 <p>The code comes with no warranty.  If it breaks, you get to keep both
1261 pieces.</p>
1262
1263 </body>
1264 </html>