1 Return-Path: mattson@dcs.gla.ac.uk
2 Return-Path: <mattson@dcs.gla.ac.uk>
3 Received: from starbuck.dcs.gla.ac.uk by goggins.dcs.gla.ac.uk
4 with LOCAL SMTP (PP) id <02535-0@goggins.dcs.gla.ac.uk>;
5 Thu, 18 Nov 1993 09:59:57 +0000
6 To: Robert.Corbett@Eng.Sun.COM
7 cc: partain@dcs.gla.ac.uk
8 Subject: Re: [Robert.Corbett@Eng.Sun.COM: Re: possible bug, byacc 1.9]
9 In-reply-to: Your message from 9:46 AM GMT
10 Date: Thu, 18 Nov 93 09:59:53 +0000
11 From: Jim Mattson <mattson@dcs.gla.ac.uk>
13 It's clear that this feature improves error detection, but it's not
14 clear to me how it improves the scope of possible error recoveries.
16 If I understand your explanation, it sounds like the only alternative
17 (short of changing the byacc source) is to add tens or hundreds of
18 error productions sprinkled throughout the code anywhere that an
19 unexpected symbol may appear, since no intervening reductions are
22 Although the addition of all of these error productions increases the
23 scope of possible error recoveries, the same functionality (with, in fact,
24 the same approach) is provided by other versions of yacc. The apparent
25 advantage of other versions of yacc is that they provide a facility by
26 which a single _default_ error production can handle a number of
27 possibilities (after some possibly illegal reductions have been performed).
29 Am I missing something?
33 In reply to the following message:
36 ------- Forwarded Message
38 Date: Wed, 17 Nov 93 22:33:44 PST
39 From: Robert.Corbett@Eng.Sun.COM (Robert Corbett)
40 Message-Id: <9311180633.AA07545@lupa.Eng.Sun.COM>
41 To: partain@dcs.gla.ac.uk
42 Subject: Re: possible bug, byacc 1.9
44 It is a feature. One difference between Berkeley Yacc and its
45 predecessors is that the parsers Berkeley Yacc produces detect
46 errors as soon as possible. That will lead to different behavior.
48 In this particular case, the token "IN" is not a permitted
49 lookahead symbol in state 390. AT&T Yacc parsers will not detect
50 the error until after doing more reductions than Berkeley Yacc
51 parsers. Doing reductions in illegal contexts limits the scope of
52 recoveries that are possible (unless backtracking is possible).
54 I am sorry that my attempt to provide better error detection is
55 causing you trouble. You can get the AT&T Yacc behavior by
56 replacing the routine sole_reduction in mkpar.c with a routine
57 that returns the most frequently occurring reduction.
62 - ----- Begin Included Message -----
64 >From partain@dcs.gla.ac.uk Wed Nov 17 05:03:44 1993
65 To: robert.corbett@Eng
66 Subject: possible bug, byacc 1.9
67 Date: Wed, 17 Nov 93 12:33:42 +0000
68 From: Will Partain <partain@dcs.gla.ac.uk>
70 Sadly, it's in a *HUGE* grammar, which I will send you if you have the
73 The problem occurs where {Sun's /usr/lang/yacc, bison} say:
77 aexp -> var . (rule 356)
78 aexp -> var . AT aexp (rule 366)
80 AT shift, and go to state 508
81 $default reduce using rule 356 (aexp)
87 aexp : var . AT aexp (366)
103 DOUBLEPRIM reduce 356
129 The token that comes in is "IN"; bison/sun-yacc-generated parser
130 tickles the default, reduces to "aexp", but byacc-generated tickles
131 "error" and the rest is history.
133 Maybe this is enough for you to exclaim, "Oh yes, that's a feature."
135 As I say, more info if you want it.
140 - ----- End Included Message -----
144 ------- End of Forwarded Message