CUP version 0.10b contains a few bug fixes from 0.10a

- %prec directive now works correctly 
	fixed by cananian@princeton.edu <C. Scott Ananian>
- Shift reduce conflicts are now correctly reported
	fixed by danwang@cs.princeton.edu <Daniel . Wang>
- Error with reporting the positon of the error token also fixed
	fixed by cananian@princeton.edu <C. Scott Ananian>
- INSTALL script now has a slightly more complex test.
- foo.java.diff included for changes from previous release

Daniel Wang
Department of Computer Science
Princeton University

Last updated:  11/16/96 [DW]
------------------------------------------------------------------------
Changes and Additions to CUP v0.9e

CUP version 0.10a is a major overhaul of CUP.  The changes are severe,
meaning no backwards compatibility to older versions.

Here are the changes:

1.  CUP now interfaces with the lexer in a completely different
manner.  In the previous releases, a new class was used for every
distinct type of terminal.  This release, however, uses only one class:
The Symbol class.  The Symbol class has three instance variables which 
are significant to the parser when passing information from the lexer.
The first is the value instance variable.  This variable contains the 
value of that terminal.  It is of the type declared as the terminal type
in the parser specification file.  The second two are the instance
variables left and right.  They should be filled with the int value of
where in the input file, character-wise, that terminal was found.

2. Terminal and non-nonterminal declarations now can be declared in two
different ways to indicate the values of the terminals or non-terminals.
The previous declarations of the form

terminal {classname} {terminal} [, terminal ...];

still works.  The classname, however indicates the type of the value of
the terminal or non-terminal, and does not indicate the type of object
placed on the parse stack.

A declaration, such as:

terminal {terminal} [, terminal ...];

indicates the terminals in the list hold no value.

3. CUP doesn't use the Symbol class for just terminals, but for all
non-terminals as well.  When a production reduces to a non-terminal, a
new Symbol is created, and the value field is filled with the value of
that non-terminal.  The user must know that the terminal and non terminal
declarations specify a type corresponding to the type of the value field
for the symbol representing that terminal or non-terminal.

4. Label references do not refer to the object on the parse stack, as in
the old CUP, but rather to the value of the value instance variable of
the Symbol that represents that terminal or non-terminal.  Hence,
references to terminal and non-terminal values is direct, as opposed to
the old CUP, where the labels referred to objects containing the value
of the terminal or non-terminal.

5. The RESULT variable refers directly to the value of the non-terminal
to which a rule reduces, rather than to the object on the parse stack.
Hence, RESULT is of the same type the non-terminal to which it reduces, 
as declared in the non terminal declaration.  Again, the reference is
direct, rather than to something that will contain the data.

6. For every label, two more variables are declared, which are the label
plus left or the label plus right.  These correspond to the left and
right locations in the input stream to which that terminal or
non-terminal came from.  These values are propagated from the input
terminals, so that the starting non-terminal should have a left value of
0 and a right value of the location of the last character read. 

7. A call to parse() or debug_parse() return a Symbol.  This Symbol is
of the start non-terminal, so the value field contains the final RESULT
assignment. 

8. CUP now has precedenced terminals.  a new declaration section,
occurring between the terminal and non-terminal declarations and the
grammar specifies the precedence and associativity of rules.  The
declarations are of the form:

precedence {left| right | nonassoc} terminal[, terminal ...];
...

The terminals are assigned a precedence, where terminals on the same
line have equal precedences, and the precedence declarations farther
down the list of precedence declarations have higher precedence.  left,
right and nonassoc specify the associativity of these terminals.  left
associativity corresponds to a reduce on conflict, right to a shift on
conflict, and nonassoc to an error on conflict.  Hence, ambiguous
grammars may now be used.  For a better explanation, see the manual.

9.  Finally the new CUP adds contextual precedence.  A production may be
declare as followed:

lhs ::= {right hand side list of terminals, non-terminals and actions}
        %prec {terminal};

this production would then have a precedence equal to the terminal
specified after the "%prec".  Hence, shift/reduce conflicts can be
contextually resolved.  Note that the "%prec terminal" part comes after
all actions strings.  It does not come before the last action string.

For more information read the manual, found in manual.html

Frank Flannery
Department of Computer Science
Princeton University

Last updated:  7/3/96 [FF]


