Related articles |
---|
Implementing scripting language: nested scopes and other problems tero.laitinen@audioriders.fi (Tero Laitinen) (2003-03-17) |
Re: Implementing scripting language: nested scopes and other problems cdodd@acm.org (Chris Dodd) (2003-03-22) |
From: | Chris Dodd <cdodd@acm.org> |
Newsgroups: | comp.compilers |
Date: | 22 Mar 2003 15:56:57 -0500 |
Organization: | Compilers Central |
References: | 03-03-115 |
Keywords: | design, interpreter |
Posted-Date: | 22 Mar 2003 15:56:57 EST |
Tero Laitinen <tero.laitinen@audioriders.fi> 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",
$3, $1->type->name);
$$ = 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.
Other notes:
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).
Chris Dodd
cdodd@acm.org
Return to the
comp.compilers page.
Search the
comp.compilers archives again.