From: | Mike Burrell <mburrel@uwo.ca> |
Newsgroups: | comp.compilers |
Date: | Sat, 19 May 2007 12:55:52 GMT |
Organization: | University of Western Ontario |
References: | 07-05-067 |
Keywords: | parse, symbols |
Posted-Date: | 20 May 2007 22:07:04 EDT |
On 2007-05-18 00:43:38 -0400, Ryan Dary <iecc@ryandary.com> said:
> Dim a As Integer = i + 10
*snip*
> 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?
That's one way to do it, and it's been done before.
The usual way to do it is to just let 'i' be an identifier. Thus in
your syntax tree, you'll have IDENTIFIER + CONSTANT for your
expression. If your language has dynamic semantics/typing, then you'll
be content with that and go on your merry way executing, only checking
what 'i' is once you've reached that line in your thread of execution.
If your language has static semantics/typing, then after you do your
parsing, you'll have another phase in your compiler where you make
sense of what the identifiers refer to.
Mike
Return to the
comp.compilers page.
Search the
comp.compilers archives again.