From: | "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> |
Newsgroups: | comp.compilers |
Date: | Sat, 19 May 2007 09:34:06 +0200 |
Organization: | cbb software GmbH |
References: | 07-05-067 |
Keywords: | parse, symbols |
Posted-Date: | 20 May 2007 22:06:29 EDT |
On Thu, 17 May 2007 21:43:38 -0700, Ryan Dary wrote:
> 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.
Why do you want to know anything more than "'i' is an identifier"? The only
thing you really need to know when parsing <expr> is the tokens of.
Identifier is a token and usually the language defines a formal way of
recognizing identifiers in the source without looking into any symbol
tables. So it could be something like: starts with a letter, has digits,
letters and underscore, not a reserved word. It is also a good idea to add
an additional level of delimiters like semicolons at the statements ends.
This makes reading programs easier and for parsing it would mean a
possibility to recover after typo errors.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Return to the
comp.compilers page.
Search the
comp.compilers archives again.