Mail Archives: djgpp/1999/07/12/11:20:21
Martin Str|mberg wrote:
> Endlisnis (s257m AT unb DOT ca) wrote:
> : That is sort-of what I've been doing, but to do the parsing correctly, I need to
> : know if "b" is a type-specifier or an ID. And the reduce/reduce errors are in the
> No. At the parsing stage, it seems to me from your problem desciption,
> all you know is that "b" is an ID (which could be a type or a
> variable).
The code was (C++):
struct {int c,d;} b;
b={1,2};
Here, 'b' is a variable-name, and should be known as a variable-name in the parsing stage
immediately after the ";". But, because of Bison's (or yacc's) look-ahead token, the 2nd
'b' has already been tokenized as an ID, which is not allowed as an rValue in an
expression, thus producing a parse error.
The real, IMPORTANT question (for a bison/yacc expert):
Is there any way to change the type associated with a token that already exists in the
Bison/yacc internal array of tokens. If that is unclear, maybe this code fragment will
help. (this is incomplete and would not work without extensive modification)
#define ID 889
#define VAR 890
int yylex() {return ID;}
//Inside Bison/yacc code
decl: ID ";" {_yacc_internal[value] = VAR;}
assignment: VAR '=' ID
What I want is the "assignment" rule to be executed even though the "VAR" id never gets
returned (please ignore the fact that yylex will never return ";" or "="). As I
understand, bison stores the return values from yylex in an array which gets shifted and
combined using all of the rules. Is there any way that I can modify the contents of that
array.
--
-Rolf Campbell (39)3-6318
- Raw text -