| 1 | From phr Tue Jul 8 10:36:19 1986 |
| 2 | Date: Tue, 8 Jul 86 00:52:24 EDT |
| 3 | From: phr (Paul Rubin) |
| 4 | To: riferguson%watmath.waterloo.edu@CSNET-RELAY.ARPA, tower |
| 5 | Subject: Re: Bison documentation? |
| 6 | |
| 7 | The main difference between Bison and Yacc that I know of is that |
| 8 | Bison supports the @N construction, which gives you access to |
| 9 | the starting and ending line number and character number associated |
| 10 | with any of the symbols in the current rule. |
| 11 | |
| 12 | Also, Bison supports the command `%expect N' which says not to mention |
| 13 | the conflicts if there are N shift/reduce conflicts and no reduce/reduce |
| 14 | conflicts. |
| 15 | |
| 16 | The differences in the algorithms stem mainly from the horrible |
| 17 | kludges that Johnson had to perpetrate to make Yacc fit in a PDP-11. |
| 18 | |
| 19 | Also, Bison uses a faster but less space-efficient encoding for the |
| 20 | parse tables (see Corbett's PhD thesis from Berkeley, "Static |
| 21 | Semantics in Compiler Error Recovery", June 1985, Report No. UCB/CSD |
| 22 | 85/251), and more modern technique for generating the look-ahead sets. |
| 23 | (See Frank DeRemer and Thomas Pennello, "Efficient Computation of |
| 24 | LALR(1) Look-Ahead Sets", ACM Transactions on Programming Languages |
| 25 | and Systems (TOPLAS) 4, 4 (October 1982), 615-649. Their |
| 26 | technique is the standard one now.) |
| 27 | |
| 28 | paul rubin |
| 29 | free software foundation |
| 30 | |
| 31 | |
| 32 | [DeRemer-Pennello reference corrected by Paul Eggert <eggert@cs.ucla.edu>, |
| 33 | 2004-06-21.] |