Re: Am I parsing this correctly? (when do I build the symbol table)

SM Ryan <wyrmwif@tsoft.org>
Sat, 19 May 2007 06:30:50 -0000

          From comp.compilers

Related articles
Am I parsing this correctly? (when do I build the symbol table) iecc@ryandary.com (Ryan Dary) (2007-05-17)
Re: Am I parsing this correctly? (when do I build the symbol table) wyrmwif@tsoft.org (SM Ryan) (2007-05-19)
Re: Am I parsing this correctly? (when do I build the symbol table) mailbox@dmitry-kazakov.de (Dmitry A. Kazakov) (2007-05-19)
Re: Am I parsing this correctly? (when do I build the symbol table) DrDiettrich1@aol.com (Hans-Peter Diettrich) (2007-05-19)
Re: Am I parsing this correctly? (when do I build the symbol table) mburrel@uwo.ca (Mike Burrell) (2007-05-19)
Re: Am I parsing this correctly? (when do I build the symbol table) jeffrey.kenton@comcast.net (Jeff Kenton) (2007-05-19)
Re: Am I parsing this correctly? (when do I build the symbol table) gneuner2@comcast.net (George Neuner) (2007-05-19)
Re: Am I parsing this correctly? (when do I build the symbol table) 148f3wg02@sneakemail.com (Karsten Nyblad) (2007-05-20)
[5 later articles]
| List of all articles for this month |

From: SM Ryan <wyrmwif@tsoft.org>
Newsgroups: comp.compilers
Date: Sat, 19 May 2007 06:30:50 -0000
Organization: Quick STOP Groceries
References: 07-05-067
Keywords: parse
Posted-Date: 20 May 2007 22:06:11 EDT

Ryan Dary <iecc@ryandary.com> wrote:
# I'm working on a phase of my compiler. The language is similar to
# Visual Basic, and I want to know if I'm parsing this correctly.


Unclean! Unclean!


# as I parse the Dim statement (which is used to declare a variable), I
# am able to parse the components "Dim a As Integer = <exp>" where the
# <exp> (expression) seems to be impossible to really parse without
# having a symbol table thus far in the parsing. I wouldn't know if "i"
# is a variable or a function or a constant, because I don't have any


Rather than make a parse tree node labelled 'variable' or 'function' or
'constant', make a node labelled 'identifier' and then come back later
and edit the node with parse tree information. You only have a problem
when you cannot proceed with the parse when confronted by a identifier
with no further information. For example in C, the construct
f(X);
can be either a function call, if f is a function, or declaration of X
if f is type name. To parse C you have to maintain a stack of typedef
names as you parse. Algol68 has a similar problem with tab tag = value
is (tab tag) = value if tab is operator, or a declaration tab (tag = value)
if tab is a mode indication; further complicated because Algol68 allows
forward references.


If in your language you know that Dim must be followed by a variable name
and that = must be followed by an expression and an identifier in an
expression must be an application of variable, function, or constant
defined elsewhere, then you can parse without knowing exactly what it
will be defined as.


# way of looking it up in a symbol table. So, should I be building the
# symbol table as I'm parsing the syntax tree from the tokens?


If the scope rules forbid any use of a identifier before it is defined,
you can possibly combine the symbol identification with the parse; this
is case with Pascal, Ada, and now C. If the scope rules allow forward
references, as Algol 60 and 68, you have to complete the parse to ensure
you have all definitions available, which might follow usage.


--
SM Ryan http://www.rawbw.com/~wyrmwif/
There are subtler ways of badgering a witness.


Post a followup to this message

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