SQLite

Check-in [d1e211fad9]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:documentation update (CVS 224)
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: d1e211fad9d787a0fdbcd11fb364d6c592c07a05
User & Date: drh 2001-06-08 00:25:18.000
Context
2001-06-10
19:56
All BTree code is in place. Now we just have to make it work. (CVS 225) (check-in: d4be4709ee user: drh tags: trunk)
2001-06-08
00:25
documentation update (CVS 224) (check-in: d1e211fad9 user: drh tags: trunk)
00:21
incremental update (CVS 223) (check-in: 7108b699cc user: drh tags: trunk)
Changes
Unified Diff Ignore Whitespace Patch
Changes to doc/lemon.html.
511
512
513
514
515
516
517



518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537





























538
539
540
541
542
543
544
the grammar rules, or after the grammar rules, or in the mist of the
grammar rules.  It doesn't matter.  The relative order of
directives used to assign precedence to terminals is important, but
other than that, the order of directives in Lemon is arbitrary.</p>

<p>Lemon supports the following special directives:
<ul>



<li><tt>%destructor</tt>
<li><tt>%extra_argument</tt>
<li><tt>%include</tt>
<li><tt>%left</tt>
<li><tt>%name</tt>
<li><tt>%nonassoc</tt>
<li><tt>%parse_accept</tt>
<li><tt>%parse_failure </tt>
<li><tt>%right</tt>
<li><tt>%stack_overflow</tt>
<li><tt>%stack_size</tt>
<li><tt>%start_symbol</tt>
<li><tt>%syntax_error</tt>
<li><tt>%token_destructor</tt>
<li><tt>%token_prefix</tt>
<li><tt>%token_type</tt>
<li><tt>%type</tt>
</ul>
Each of these directives will be described separately in the
following sections:</p>






























<h4>The <tt>%destructor</tt> directive</h4>

<p>The %destructor directive is used to specify a destructor for
a non-terminal symbol.
(See also the %token_destructor directive which is used to
specify a destructor for terminal symbols.)</p>







>
>
>




















>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>







511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
the grammar rules, or after the grammar rules, or in the mist of the
grammar rules.  It doesn't matter.  The relative order of
directives used to assign precedence to terminals is important, but
other than that, the order of directives in Lemon is arbitrary.</p>

<p>Lemon supports the following special directives:
<ul>
<li><tt>%code</tt>
<li><tt>%default_destructor</tt>
<li><tt>%default_type</tt>
<li><tt>%destructor</tt>
<li><tt>%extra_argument</tt>
<li><tt>%include</tt>
<li><tt>%left</tt>
<li><tt>%name</tt>
<li><tt>%nonassoc</tt>
<li><tt>%parse_accept</tt>
<li><tt>%parse_failure </tt>
<li><tt>%right</tt>
<li><tt>%stack_overflow</tt>
<li><tt>%stack_size</tt>
<li><tt>%start_symbol</tt>
<li><tt>%syntax_error</tt>
<li><tt>%token_destructor</tt>
<li><tt>%token_prefix</tt>
<li><tt>%token_type</tt>
<li><tt>%type</tt>
</ul>
Each of these directives will be described separately in the
following sections:</p>

<h4>The <tt>%code</tt> directive</h4>

<p>The %code directive is used to specify addition C/C++ code that
is added to the end of the main output file.  This is similar to
the %include directive except that %include is inserted at the
beginning of the main output file.</p>

<p>%code is typically used to include some action routines or perhaps
a tokenizer as part of the output file.</p>

<h4>The <tt>%default_destructor</tt> directive</h4>

<p>The %default_destructor directive specifies a destructor to 
use for non-terminals that do not have their own destructor
specified by a separate %destructor directive.  See the documentation
on the %destructor directive below for additional information.</p>

<p>In some grammers, many different non-terminal symbols have the
same datatype and hence the same destructor.  This directive is
a convenience way to specify the same destructor for all those
non-terminals using a single statement.</p>

<h4>The <tt>%default_type</tt> directive</h4>

<p>The %default_type directive specifies the datatype of non-terminal
symbols that do no have their own datatype defined using a separate
%type directive.  See the documentation on %type below for addition
information.</p>

<h4>The <tt>%destructor</tt> directive</h4>

<p>The %destructor directive is used to specify a destructor for
a non-terminal symbol.
(See also the %token_destructor directive which is used to
specify a destructor for terminal symbols.)</p>
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
a variable named ``pAbc'' that is the value of the 4th parameter
in the most recent call to Parse().</p>

<h4>The <tt>%include</tt> directive</h4>

<p>The %include directive specifies C code that is included at the
top of the generated parser.  You can include any text you want --
the Lemon parser generator copies to blindly.  If you have multiple
%include directives in your grammar file, their values are concatenated
before being put at the beginning of the generated parser.</p>

<p>The %include directive is very handy for getting some extra #include
preprocessor statements at the beginning of the generated parser.
For example:</p>

<p><pre>
   %include {#include &lt;unistd.h&gt;}







|
|
|







635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
a variable named ``pAbc'' that is the value of the 4th parameter
in the most recent call to Parse().</p>

<h4>The <tt>%include</tt> directive</h4>

<p>The %include directive specifies C code that is included at the
top of the generated parser.  You can include any text you want --
the Lemon parser generator copies it blindly.  If you have multiple
%include directives in your grammar file the value of the last
%include directive overwrites all the others.</p.

<p>The %include directive is very handy for getting some extra #include
preprocessor statements at the beginning of the generated parser.
For example:</p>

<p><pre>
   %include {#include &lt;unistd.h&gt;}
Changes to notes/notes3.txt.
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
  const char **sqlite_columns(sqlite*);
  int sqlite_argc(sqlite*);
  const char **sqlite_argv(sqlite*);
  char *sqlite_vmprintf(const char *zFormat, va_list);
  int sqlite_table(sqlite*, int *nrow, int *ncolumn, const char ***argv);
  void sqlite_busy_handler(sqlite*, int(*)(void*,const char*,int), void*);

Access routines that are implement derived from primary and sec
  
  char *sqlite_mprintf(const char *zFormat, ...);
  int sqlite_compile_vprintf(sqlite*, const char *zFormat, va_list);
  int sqlite_compile_printf(sqlite*, const char *zFormat, ...);
  int sqlite_busy_timeout(sqlite*, int ms);

The C++ interface is obvious...







|







20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
  const char **sqlite_columns(sqlite*);
  int sqlite_argc(sqlite*);
  const char **sqlite_argv(sqlite*);
  char *sqlite_vmprintf(const char *zFormat, va_list);
  int sqlite_table(sqlite*, int *nrow, int *ncolumn, const char ***argv);
  void sqlite_busy_handler(sqlite*, int(*)(void*,const char*,int), void*);

Access routines that are derived from primary and secondary:
  
  char *sqlite_mprintf(const char *zFormat, ...);
  int sqlite_compile_vprintf(sqlite*, const char *zFormat, va_list);
  int sqlite_compile_printf(sqlite*, const char *zFormat, ...);
  int sqlite_busy_timeout(sqlite*, int ms);

The C++ interface is obvious...