gram.y says:

opt_indirection:  ...
                | '[' a_expr ']' opt_indirection
                | '[' a_expr ':' a_expr ']' opt_indirection
		...

IMO a_expr is exactly where I have to enter C variable support. That is I
add a new case to a_expr: named cinputvariable which among others might have
the following form:

cinputvariable: /* empty */
		...
		| ':' name ':' name
		...

With the first name being the variable, the second being the the name of the
indicator variable. As you might expect this results in a shift/reduce
conflict since there is no way to decide whether the second name is the
indicator variable or a coloumn name.

Any idea how to solve this?

Michael
-- 
Dr. Michael Meskes, Project-Manager    | topsystem Systemhaus GmbH
meskes@topsystem.de                    | Europark A2, Adenauerstr. 20
meskes@debian.org                      | 52146 Wuerselen
Go SF49ers! Go Rhein Fire!             | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux!                  | Fax: (+49) 2405/4670-10

Mon, 20 Apr 1998 15:21:51 +0200 (CEST)
Michael Meskes <meskes@topsystem.de>
shift/reduce problem with ecpg
> gram.y says:
> 
> opt_indirection:  ...
>                 | '[' a_expr ']' opt_indirection
>                 | '[' a_expr ':' a_expr ']' opt_indirection
>                 ...
> 
> IMO a_expr is exactly where I have to enter C variable support.
> As you might expect this results in a shift/reduce
> conflict since there is no way to decide whether the second name is 
> the indicator variable or a coloumn name.
> 
> Any idea how to solve this?

Yes. If you really want to allow zero, one, or two colons, and only that
number, then you can explicitly define those cases and separate them out
from the a_expr syntax except as an argument. Look in gram.y for
"b_expr" which accomplishes a similar thing for the BETWEEN operator.
For that case, the AND usage was ambiguous since it can be used for
boolean expressions and is also used with the BETWEEN operator.

Your biggest problem is probably the case with one colon, since it could
be either an indicator variable or the second value in a range. You
might want to require three or four colons when using indicator
variables in this context. Or, as I did with the "b_expr" and "AND"
boolean expressions, you can require parens around the
variable/indicator pair. e.g.

 xxx [ name : name ]      -- this is a range
 xxx [ (name : name) ]    -- this is an indicator variable

                          - Tom

Tue, 21 Apr 1998 05:42:39 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] shift/reduce problem with ecpg
Thomas G. Lockhart writes:
> Yes. If you really want to allow zero, one, or two colons, and only that
> number, then you can explicitly define those cases and separate them out
> from the a_expr syntax except as an argument. Look in gram.y for
> "b_expr" which accomplishes a similar thing for the BETWEEN operator.
> For that case, the AND usage was ambiguous since it can be used for
> boolean expressions and is also used with the BETWEEN operator.

Thanks Thomas. I've created a c_expr to be used in opt_indirection. Since
indicators don't make sense in this position only variables may be entered
here. 

Michael

-- 
Dr. Michael Meskes, Project-Manager    | topsystem Systemhaus GmbH
meskes@topsystem.de                    | Europark A2, Adenauerstr. 20
meskes@debian.org                      | 52146 Wuerselen
Go SF49ers! Go Rhein Fire!             | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux!                  | Fax: (+49) 2405/4670-10

Tue, 21 Apr 1998 12:34:25 +0200 (CEST)
Michael Meskes <meskes@topsystem.de>
Re: [HACKERS] shift/reduce problem with ecpg