Re: How to design a symbol table?

"Rodney M. Bates" <rbates@southwind.net>
17 Oct 2004 16:10:39 -0400

          From comp.compilers

Related articles
How to design a symbol table? chris@tkdsoftware.com (2004-10-09)
Re: How to design a symbol table? torbenm@diku.dk (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? rbates@southwind.net (Rodney M. Bates) (2004-10-17)
Re: How to design a symbol table? nmm1@cus.cam.ac.uk (2004-10-21)
Re: How to design a symbol table? skaller@nospam.com.au (John Max Skaller) (2004-10-21)
| List of all articles for this month |

From: "Rodney M. Bates" <rbates@southwind.net>
Newsgroups: comp.compilers
Date: 17 Oct 2004 16:10:39 -0400
Organization: EarthLink Inc. -- http://www.EarthLink.net
References: 04-10-075 04-10-103
Keywords: symbols
Posted-Date: 17 Oct 2004 16:10:39 EDT

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.


I have used this technique on a modest special-propose language, with
success, and thought the coding was, if anything, simplified by not
needing a separate set of data structure more or structurally
equivalent to the AST subtrees for declarations. On the other hand,
the AST isn't quite as ideal a shape for representing types, etc., as
an separately-designed data structure. I guess it would be horrible
for C/C++ types, where it is undoubtedly better to convert to a
consistent form.


Anybody have other experience with this approach?


Jeff Kenton wrote:
> The simple answer: everything relevant goes in the symbol table, and the
> declaration disappears from the AST.


Post a followup to this message

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