Re: How to design a symbol table? (Nick Maclaren)
21 Oct 2004 22:20:24 -0400

          From comp.compilers

Related articles
How to design a symbol table? (2004-10-09)
Re: How to design a symbol table? (2004-10-12)
Re: How to design a symbol table? (Jeff Kenton) (2004-10-12)
Re: How to design a symbol table? (Rodney M. Bates) (2004-10-17)
Re: How to design a symbol table? (2004-10-21)
Re: How to design a symbol table? (John Max Skaller) (2004-10-21)
| List of all articles for this month |

From: (Nick Maclaren)
Newsgroups: comp.compilers
Date: 21 Oct 2004 22:20:24 -0400
Organization: University of Cambridge, England
References: 04-10-075 04-10-103 04-10-126
Keywords: symbols
Posted-Date: 21 Oct 2004 22:20:23 EDT

Rodney M. Bates <> 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.

Nick Maclaren.

Post a followup to this message

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