Re: Implementing scripting language: nested scopes and other problems

Chris Dodd <cdodd@acm.org>
22 Mar 2003 15:56:57 -0500

          From comp.compilers

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)
| List of all articles for this month |

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


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.