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

On May 18, 12:43 am, Ryan Dary <iecc AT ryandary.com> 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.


Well, personally I'm a bit of a procrastinator, but when I've written
compilers I've always been a fan of the "do it now" philosophy, also
because I tend to like to write compilers as one pass whenever I can
get away with it. The sooner you do anything the less you have to
fuss with it and the faster you get rid of it.


Note that in the following I use "procedure" to refer to both the sub
and the function. This is so I don't have to remember which is which,
because, for the purposes of this discussion it doesn't matter whether
these are subs or functions.


So, given the above code, in the first procedure (do_something_else),
you define i as a (writable) parameter passed to you from the caller,
I would create the identifier table as soon as I see the identifier.
The variable i then becomes a kind of global variable, say an
internediate variable, so that if there is a global variable named i
the parameter overrides it,or however you would handle a parameter
variable as opposed to a local variable or a global one (if you handle
them differently).


Now, in the second procedure (do_something), what I would do is change
the name of the parameter i to something else with a name that is only
available for internal use. Now, you do a create of a local variable
named i of the same type as this internal variable that parameter i
was named to (integer in this case). Now, I would set up a "prefix
code" array or table, that says, before you write the executable code
for this procedure, you generate this code at the beginning of the
procedure, e.g. you prefix this code ahead of any code in the
procedure. And in that prefix code, I would do an assignment of
parameter i to local i (because your parameter here is non-
writable). By translating the parameter into a local variable and
copying it, you don't have to worry if the procedure trashes it or
what it does with the variable, it's a local variable, instantiated
when the procedure is invoked and is destroyed when the procedure
ends.


Now, when you get to the statement Dim a As Integer = i + 10 you
create a local variable a, and in the prefix code table, as the second
thing to do before generating any code for this procedure, is a
statement assigning the value of I+10 to a. Since the first thing in
the prefix code is to copy parameter i to local i, you're done
worrying about it.


What you could do is, to make it simpler and push the code generation
to later, is have the "prefix code" table consist of statments in the
language, and the compiler simply does this: when it reaches the first
executable line of code in a procedure, if the prefix code table is
not empty, it reads those first (until exhausted) as if the table was
a form of an include file immediately before the first line of
executable code. The compiler won't care, all it's doing is compiling
valid code, and the result provides what you need.


Now, that's how I would do it. Maybe that's not the "best" way, but
it is fairly simple - at least I think it's simple - and I like simple
ways to solve problems.


Paul Robinson - http://paul-robinson.us (My Blog)
"The lessons of history teach us - if they teach us anything - that
nobody learns the lessons that history teaches us."

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