4.3BSD-Tahoe/usr/src/usr.bin/yacc/yaccnews
5/18/78
A new version of Yacc has been installed which contains some new
features relating to error recovery, detection of funny conditions in the
grammar, and strong typing. Existing grammars should continue to work,
with the possible exception of somewhat better error recovery behavior.
More details follow:
*** Ratfor and EFL Yacc are dead. Long live C!
*** The y.tab.c file now uses the # line feature to reflect
most error conditions in actions, etc., back to the yacc source
file, rather than the y.tab.c file. As always with such features,
lookahead may cause the line number to be one too large
occasionally.
*** The error recovery algorithm has been changed to cause the
parser never to reduce on a state where there is a shift
on the special token `error'. This has the effect of causing
the error recovery action to take place somewhat closer to the
location of the error than previously. It does not affect the
behavior of the parser in the absence of errors. The parse
tables may be 1-2% larger as a result of this change.
*** Yacc now detects the existence of nonterminals in the grammar
which can never derive any strings of tokens (even the empty string).
The simplest example is the grammar:
%%
s : s 'a' ;
Here, one must reduce `s' in order to reduce `s': the
parser would always report error. If such nonterminals are
present, Yacc reports all such, then terminates.
*** There is a new reserved word, %start. When used in the declarations
section, it may be used to declare the start symbol of the grammar.
If %start does not appear, the start symbol is, as at present, the
first nonterminal symbol encountered.
*** Yacc produced parsers are notorious for producing many many
comments from lint. The problem is the value stack of the
parser, which typically may contain integers, pointers, and
possibly even floating point, etc., values. The lack
of tight specification of this stack leads to potential
nonportability, and considerable loss of the diagnostic power
of lint. Thus, some new features have been added which make use
of the new structure and union facilities of C. In effect,
the user of Yacc may `honestly' declare the value stack, as
well as the lexical interface variable, yylval, to be unions
of all the types desired. Yacc will keep track of the types
declared for all terminals and nonterminals, and automatically
insert the appropriate union tag for all constructions such
as $1, $$, etc. It is up to the user to supply the appropriate
union declaration, and to declare the type of all the terminal
and nonterminal symbols which will have values. If the type
declaration feature is used at all, it must be used correctly;
if it is not used, the default values are integers, as at present.
The new type declaration features are described below:
*** There is a new keyword, %union. A construction such as
%union {
int inttag;
float floattag;
struct mumble *ptrtag;
}
can be used, in the declarations section, to declare
the type of the yacc stack. The declaration is
effectively copied to the y.tab.c file, and, if the -d
option is present, to the y.tab.h file as well. The
declaration is used to declare the typedef YYSTYPE, which is the
type of the value stack. If the -d option is present,
the declaration
extern YYSTYPE yylval;
is also placed onto the y.tab.h file. Note that the lexical
analyzer must be changed to use the appropriate union tag when
assigning values. It is not necessary that the %union
mechanism be used, as long as there is a union type YYSTYPE
defined in the declarations section.
*** The %token, %left, %right, and %nonassoc declarations now
accept a union tag, enclosed in angle brackets (<...>), immediately
after the keyword. All tokens mentioned in that declaration are
taken to have the appropriate type.
*** There is a new keyword, %type, also followed by a union tag
in angle brackets, which may be used in the declarations section to
declare nonterminal symbols to have a particular type.
In both cases, whenever a $$ or $n is encountered in an action,
the appropriate union tag is supplied by Yacc. Once any type is
declared, it is an error to use a $$ or $n whose type is unknown.
It is also illegal to have a grammar rule whose LHS has a type,
but the rule has no action and the default action { $$ = $1; }
would be inapplicable because $1 had a different type.
*** There are occasional times when the type of something is
not known (for example, when an action within a rule returns a
value). In this case, the $$ and $n syntax is extended
to permit the declaration of the type: the syntax is
$<tag>$
and
$<tag>n
respectively. This rather strange syntax is necessitated by the
need to distinguish the <> surrounding the tag from the < and >
operators of C in the action. It is anticipated that the usage
will be rare.
*** As always, report gripes, bugs, suggestions to SCJ ***
12/01/76
A newer version of Yacc has been installed which copies the actions directly
into the parser, rather than gathering them into a separate routine.
The advantages include
1. It's faster
2. You can return a value from yyparse (and stop parsing...) by
saying `return(x);' in an action
3. There are macros which simulate various interesting parsing
actions:
YYERROR causes the parser to behave as if a syntax
error had been encountered (i.e., do error recovery)
YYACCEPT causes a return from yyparse with a value of 0
YYABORT causes a return from yyparse with a value of 1
The repositioning of the actions may cause scope problems
for some people who include lexical analyzers in funny places.
This can probably be avoided by using another
new feature: the `-d' option.
Invoking Yacc with the -d option causes the #defines
generated by Yacc to be written out onto a file
called "y.tab.h". This can then be included as desired
in lexical analyzers, etc.
11/28/76
A new version of Yacc has been installed which permits actions within
rules. For such actions, $$ and $1, $2, etc. continue to have their
usual meanings. An error message is returned if any $n refers to
a value lying to the right of the action in the rule.
These internal actions are assumed to return a value, which is accessed
through the $n mechanism.
In the y.output file, the actions are referred to by created nonterminal
names of the form $$nnn.
All actions within rules are assumed to be distinct. If some actions
are the same, Yacc might report reduce/reduce conflicts which could
be resolved by explicitly identifying identical actions; does anyone
have a good idea for a syntax to do this?
In the new Yacc, the = sign may now be omitted in action constructions
of the form ={ ... }