home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Fresh Fish 5
/
FreshFish_July-August1994.bin
/
bbs
/
gnu
/
bison-1.22-bin.lha
/
info
/
bison.info-2
(
.txt
)
< prev
next >
Wrap
GNU Info File
|
1994-07-11
|
48KB
|
1,024 lines
This is Info file bison.info, produced by Makeinfo-1.54 from the input
file /home/gd2/gnu/bison/bison.texinfo.
This file documents the Bison parser generator.
Copyright (C) 1988, 1989, 1990, 1991, 1992 Free Software Foundation,
Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.
Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided also
that the sections entitled "GNU General Public License" and "Conditions
for Using Bison" are included exactly as in the original, and provided
that the entire resulting derived work is distributed under the terms
of a permission notice identical to this one.
Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that the sections entitled "GNU General Public
License", "Conditions for Using Bison" and this permission notice may be
included in translations approved by the Free Software Foundation
instead of in the original English.
File: bison.info, Node: Rpcalc Rules, Next: Rpcalc Lexer, Prev: Rpcalc Decls, Up: RPN Calc
Grammar Rules for `rpcalc'
--------------------------
Here are the grammar rules for the reverse polish notation
calculator.
input: /* empty */
| input line
;
line: '\n'
| exp '\n' { printf ("\t%.10g\n", $1); }
;
exp: NUM { $$ = $1; }
| exp exp '+' { $$ = $1 + $2; }
| exp exp '-' { $$ = $1 - $2; }
| exp exp '*' { $$ = $1 * $2; }
| exp exp '/' { $$ = $1 / $2; }
/* Exponentiation */
| exp exp '^' { $$ = pow ($1, $2); }
/* Unary minus */
| exp 'n' { $$ = -$1; }
;
%%
The groupings of the rpcalc "language" defined here are the
expression (given the name `exp'), the line of input (`line'), and the
complete input transcript (`input'). Each of these nonterminal symbols
has several alternate rules, joined by the `|' punctuator which is read
as "or". The following sections explain what these rules mean.
The semantics of the language is determined by the actions taken
when a grouping is recognized. The actions are the C code that appears
inside braces. *Note Actions::.
You must specify these actions in C, but Bison provides the means for
passing semantic values between the rules. In each action, the
pseudo-variable `$$' stands for the semantic value for the grouping
that the rule is going to construct. Assigning a value to `$$' is the
main job of most actions. The semantic values of the components of the
rule are referred to as `$1', `$2', and so on.
* Menu:
* Rpcalc Input::
* Rpcalc Line::
* Rpcalc Expr::
File: bison.info, Node: Rpcalc Input, Next: Rpcalc Line, Up: Rpcalc Rules
Explanation of `input'
......................
Consider the definition of `input':
input: /* empty */
| input line
;
This definition reads as follows: "A complete input is either an
empty string, or a complete input followed by an input line". Notice
that "complete input" is defined in terms of itself. This definition
is said to be "left recursive" since `input' appears always as the
leftmost symbol in the sequence. *Note Recursive Rules: Recursion.
The first alternative is empty because there are no symbols between
the colon and the first `|'; this means that `input' can match an empty
string of input (no tokens). We write the rules this way because it is
legitimate to type `Ctrl-d' right after you start the calculator. It's
conventional to put an empty alternative first and write the comment
`/* empty */' in it.
The second alternate rule (`input line') handles all nontrivial
input. It means, "After reading any number of lines, read one more
line if possible." The left recursion makes this rule into a loop.
Since the first alternative matches empty input, the loop can be
executed zero or more times.
The parser function `yyparse' continues to process input until a
grammatical error is seen or the lexical analyzer says there are no more
input tokens; we will arrange for the latter to happen at end of file.
File: bison.info, Node: Rpcalc Line, Next: Rpcalc Expr, Prev: Rpcalc Input, Up: Rpcalc Rules
Explanation of `line'
.....................
Now consider the definition of `line':
line: '\n'
| exp '\n' { printf ("\t%.10g\n", $1); }
;
The first alternative is a token which is a newline character; this
means that rpcalc accepts a blank line (and ignores it, since there is
no action). The second alternative is an expression followed by a
newline. This is the alternative that makes rpcalc useful. The
semantic value of the `exp' grouping is the value of `$1' because the
`exp' in question is the first symbol in the alternative. The action
prints this value, which is the result of the computation the user
asked for.
This action is unusual because it does not assign a value to `$$'.
As a consequence, the semantic value associated with the `line' is
uninitialized (its value will be unpredictable). This would be a bug if
that value were ever used, but we don't use it: once rpcalc has printed
the value of the user's input line, that value is no longer needed.
File: bison.info, Node: Rpcalc Expr, Prev: Rpcalc Line, Up: Rpcalc Rules
Explanation of `expr'
.....................
The `exp' grouping has several rules, one for each kind of
expression. The first rule handles the simplest expressions: those
that are just numbers. The second handles an addition-expression,
which looks like two expressions followed by a plus-sign. The third
handles subtraction, and so on.
exp: NUM
| exp exp '+' { $$ = $1 + $2; }
| exp exp '-' { $$ = $1 - $2; }
...
;
We have used `|' to join all the rules for `exp', but we could
equally well have written them separately:
exp: NUM ;
exp: exp exp '+' { $$ = $1 + $2; } ;
exp: exp exp '-' { $$ = $1 - $2; } ;
...
Most of the rules have actions that compute the value of the
expression in terms of the value of its parts. For example, in the
rule for addition, `$1' refers to the first component `exp' and `$2'
refers to the second one. The third component, `'+'', has no meaningful
associated semantic value, but if it had one you could refer to it as
`$3'. When `yyparse' recognizes a sum expression using this rule, the
sum of the two subexpressions' values is produced as the value of the
entire expression. *Note Actions::.
You don't have to give an action for every rule. When a rule has no
action, Bison by default copies the value of `$1' into `$$'. This is
what happens in the first rule (the one that uses `NUM').
The formatting shown here is the recommended convention, but Bison
does not require it. You can add or change whitespace as much as you
wish. For example, this:
exp : NUM | exp exp '+' {$$ = $1 + $2; } | ...
means the same thing as this:
exp: NUM
| exp exp '+' { $$ = $1 + $2; }
| ...
The latter, however, is much more readable.
File: bison.info, Node: Rpcalc Lexer, Next: Rpcalc Main, Prev: Rpcalc Rules, Up: RPN Calc
The `rpcalc' Lexical Analyzer
-----------------------------
The lexical analyzer's job is low-level parsing: converting
characters or sequences of characters into tokens. The Bison parser
gets its tokens by calling the lexical analyzer. *Note The Lexical
Analyzer Function `yylex': Lexical.
Only a simple lexical analyzer is needed for the RPN calculator.
This lexical analyzer skips blanks and tabs, then reads in numbers as
`double' and returns them as `NUM' tokens. Any other character that
isn't part of a number is a separate token. Note that the token-code
for such a single-character token is the character itself.
The return v