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

Ryan Dary wrote:
> Take a look at this source code, and then I'll explain some problems
> that I'm having...
>
>
> Sub do_something_else( byRef i As Integer )
> i = i * 10
> End Sub
>
> Function do_something( i As Integer ) As Integer
> Dim a As Integer = i + 10
> do_something_else i
> Return a * 5
> End Function
>
>
> My understanding of the syntax tree is that I'm not supposed to be
> worried about the "meaning" of the code, but rather the "structure" of
> the code. So, I'm not building a symbol tree at this phase... the
> problem with that seems to be that I'm unable to make heads or tails
> of the lines of code within the function declaration. For instance,
> 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
> 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?
>
> So, hopefully, my nonsense explanation of my problem will make sense to
> someone who can shed some light on my question. Thanks in advance.
>
> - Ryan Dary


There is no such things as a fixed set of rules for how to design a
compiler. The design will always be influenced by the language being
compiled, and a design that will be fine for compiling one language
might be clumsy for compiling a different language. You can build the
symbol table currently with building the syntax tree, if you want to.
That is the normal way of doing it in C and C++ compilers, because those
languages are very difficult to parse without knowing if an identifier
is a type or something else. Many of us would do it anyway, because we
do not want the trouble of analyzing the tree an extra time.


However, I always recommend the KISS principle for newcomers to the
compiler business. KISS = keep it simple stupid. Do not try to do too
many things at once. Compilers are complex programs, and you are
normally best of not trying to be too smart. Otherwise you will have to
go bug hunting in routines you can barely understand, and your compiler
may never become reliable. You may be better of by building a parse
tree first and a symbol table later, simply to keep down complexity.


Also, it is common to transform the parse tree into a tree, that better
reflect the semantics of the program. At first you build a tree, where
you do not distinguish between identifiers being a constant, a variable,
or a function. When you have built the symbol table you transform the
tree into a new tree with nearly the same structure, but where you label
nodes of identifiers in accordances with what they are. If an
identifier denotes a variable, you label the nodes of that identifier
with a label stating that this is a variable. If it is a constant you
label the nodes with a label stating that this is a constant, etc. I am
currently writing on a problem where I already transform the tree twice,
and I anticipate transforming the three a third time. Each
transformation makes the tree easier to deal with for the the next phase.


Karsten Nyblad
148f3wg02 at sneakemail dot com

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