|How to design a symbol table? firstname.lastname@example.org (2004-10-09)|
|Re: How to design a symbol table? email@example.com (2004-10-12)|
|Re: How to design a symbol table? Jeffrey.Kenton@comcast.net (Jeff Kenton) (2004-10-12)|
|Re: How to design a symbol table? firstname.lastname@example.org (Rodney M. Bates) (2004-10-17)|
|Re: How to design a symbol table? email@example.com (2004-10-21)|
|Re: How to design a symbol table? firstname.lastname@example.org (John Max Skaller) (2004-10-21)|
|From:||email@example.com (Nick Maclaren)|
|Date:||21 Oct 2004 22:20:24 -0400|
|Organization:||University of Cambridge, England|
|References:||04-10-075 04-10-103 04-10-126|
|Posted-Date:||21 Oct 2004 22:20:23 EDT|
Rodney M. Bates <firstname.lastname@example.org> wrote:
>Having always done it and seen it done this way for years, I have
>recently become intrigued with the opposite approach: All the symbol
>table contains is a pointer to the AST subtree for the declaration.
>Furthermore, when a lookup is done, a copy of theisST declaration
>pointer becomes a semantic attribute of the AST node for the
>reference. Then the symbol table goes away.
That should work fairly well where the symbol is completely and
finally defined by its declaration, but wouldn't work at all well for
languages that have aspects of implicit declaration or where other
constructs can change the meaning of a symbol.
For example, all of Fortran, Algol 68 and C symbols are defined by a
combination of their declaration and their use. In the first case,
X = GNURR()
In the second case, look at the post-use disambiguation between
operators and modes.
In the last case, look at the specification of how extern, static,
inline and initialisation interact.
I agree that, if one is designing a language from scratch, it should
enable both approaches - not least because it minimises confusion for
the human reader.
Return to the
Search the comp.compilers archives again.