Received: from antares.mcs.anl.gov (mcs.anl.gov [140.221.9.6])
	by hub.org (8.9.3/8.9.3) with SMTP id NAA03756;
	Tue, 22 Jun 1999 13:05:14 -0400 (EDT)
	(envelope-from selkovjr@xnet.com)
Received: from xnet.com (selkovjr@selkovjr.xnet.com [205.243.141.67]) by
	antares.mcs.anl.gov (8.6.10/8.6.10) with ESMTP
	id MAA12302; Tue, 22 Jun 1999 12:05:11 -0500
Message-Id: <199906221705.MAA12302@antares.mcs.anl.gov>
To: Michael Meskes <meskes@postgreSQL.org>, pgsql-interfaces@postgreSQL.org
From: selkovjr@mcs.anl.gov
Subject: Re: [INTERFACES] esql\c documentation 
In-Reply-To: Your message of "Tue, 22 Jun 1999 10:46:02 +0200."
	<19990622104602.A1527@gmx.net>
Date: Tue, 22 Jun 1999 12:08:09 -0400
Sender: selkovjr@xnet.com

Michael Meskes wrote:

> Having a shift/reduce conflict means that you can find a statement that is
> incorrectly parsed. 

A shift/reduce conflict means that you can either complete or continue
to parse an expression (if .. then .. else is a famous example). You
will always have this situation when both and expression and its
leading subexpression are valid inputs. There is nothing wrong with
it: any non-trivial grammar will have shift/reduce conflict. Bison is
written to always shift, i. e. attempt to complete valid partial
expressions.

> The system will either do a shift (so the statement is
> parsed via alternative 1) or do a reduce (parsing alternative 2) but what
> you have in mind is certainly only one of these alternatives.

This is what reduce/reduce conflicts are like. They occur when two
entirely different rules can be reduced based on the same sequence of
tokens. Bison aborts and exits when it sees a reduce/reduce conflict,
so you don't have to worry about parts of your grammar not being used.

Tomas Lockhart wrote:

> If it is the kind of shift/reduce conflict reported by yacc/bison
> (rather than a less severe clarification printed in the bison "-v"
> log file) then it means that there is a significant part of your
> grammar which can *never* be reached! The parser will always choose
> one of the two possible paths in the conflict, and will never choose
> the other.  Not good if you actually wanted to use the full
> language.

Its sounds more like a mid-rule action in a clause with a shift/reduce
conflict. Inserting an action in the middle of a clause may leave some
of the rules non-functional. There are suggestions on how to fix
that, as well as other conflicts, in the bison manual.
(http://www2.informatik.uni-halle.de/lehre/sprakt/bison.html)

Most conflicts can be fixed by adding intermediate rules. When that
appears difficult, I re-write the input to add artificial tokens
before passing it to the parser.

--Gene