|Implementing scripting language: nested scopes and other problems email@example.com (Tero Laitinen) (2003-03-17)|
|Re: Implementing scripting language: nested scopes and other problems firstname.lastname@example.org (Chris Dodd) (2003-03-22)|
|From:||Chris Dodd <email@example.com>|
|Date:||22 Mar 2003 15:56:57 -0500|
|Posted-Date:||22 Mar 2003 15:56:57 EST|
Tero Laitinen <firstname.lastname@example.org> wrote
> lvalue: lvalue T_INDEX lvalue
> $$ = create_node2(FIELD_VAR, $1, $3);
This rule here is what's causing both the grammar conflicts you're seeing
and your parsing problems with looking up symbols in the wrong scope.
What would be better is a production like:
lvalue: lvalue '.' T_ID
Symbol *field = find_symbol_in_struct($1->type, $3);
if (field == NULL)
Error("reference to undeclared field %s in struct %s",
$$ = create_node(FIELD_VAR, $1, field);
The idea here is that you have a scope associated with struct (or class
or interface or ...) types that contains the members of the struct. This
isn't really a `stack' of scopes -- when looking things up you want to
search through your inheritance tree (which may be a complex graph). You
may use a stack to keep track of the current scope you're defining things
in, but that's really all the stack is used for.
Any rule that is both left- and right- recursive is always ambiguous
and will lead to gramar conflicts. Avoid them.
Never refer to yylval in your yacc/bison action code -- always use
%type and %token to set the correct types for your symbols, and refer
to them by $1 (or $2 or $3...). yylval may not actually contain info
on the symbol you think it does; yacc may have read ahead a token (so
it contains the next token's info).
Return to the
Search the comp.compilers archives again.