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] |
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.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.