From: | Ian Lance Taylor <ian(at)airs(dot)com> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
Cc: | kogorman(at)pacbell(dot)net, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Re: [GENERAL] A rare error |
Date: | 2000-10-27 07:50:28 |
Message-ID: | 20001027075028.21680.qmail@daffy.airs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Date: Thu, 26 Oct 2000 20:49:22 -0400
From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Right. Also, I believe it's possible that such a grammar will behave
differently depending on which yacc you process it with, which would be
bad. (We have not yet taken the step of insisting that pgsql's grammar
is bison-only, and I don't want to.) So ensuring that we get no shift/
reduce conflicts has been a shop rule around here all along.
Actually, even the earliest version of yacc had very simple rules,
which are inherited by all versions. In a shift/reduce conflict,
always shift. In a reduce/reduce conflict, always reduce by the rule
which appears first in the grammar file. shift/shift conflicts
indicate a grammer which is not LALR(1).
I'm pretty sure that all versions of yacc also support %left, %right,
and %nonassoc, which are simply techniques to eliminate shift/reduce
conflicts in arithmetic and other expressions.
I believe it is always possible to rewrite a grammer to eliminate all
conflicts. But the rewrite can require an explosion in the number of
rules.
Reduce/reduce conflicts can be risky because it is easy to
accidentally change the ordering of the rules while editing. But
shift/reduce conflicts are not risky. The C parser in gcc, for
example, written and maintained by parser experts, has 53 shift/reduce
conflicts.
Ian
From | Date | Subject | |
---|---|---|---|
Next Message | Grant Finnemore | 2000-10-27 08:30:19 | Re: [SQL] renaming columns... danger? |
Previous Message | Tom Lane | 2000-10-27 05:20:32 | Re: pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c) |