Re: I have managed to parse and evaluate using an AST. I got stuck in statements and block

Christian Gollwitzer <auriocus@gmx.de>
Thu, 19 Feb 2015 10:22:00 +0100

          From comp.compilers

Related articles
I have managed to parse and evaluate using an AST. I got stuck in stat mehmet.coskun@gmail.com (2015-02-18)
Re: I have managed to parse and evaluate using an AST. I got stuck in auriocus@gmx.de (Christian Gollwitzer) (2015-02-19)
Re: I have managed to parse and evaluate using an AST. I got stuck in bc@freeuk.com (BartC) (2015-02-19)
Re: I have managed to parse and evaluate using an AST. I got stuck in haberg-news@telia.com (Hans Aberg) (2015-02-20)
Re: I have managed to parse and evaluate using an AST. I got stuck in bc@freeuk.com (BartC) (2015-02-21)
Re: I have managed to parse and evaluate using an AST. I got stuck in mehmet.coskun@gmail.com (2015-03-05)
| List of all articles for this month |

From: Christian Gollwitzer <auriocus@gmx.de>
Newsgroups: comp.compilers
Date: Thu, 19 Feb 2015 10:22:00 +0100
Organization: A noiseless patient Spider
References: 15-02-027
Keywords: interpreter, parse
Posted-Date: 19 Feb 2015 18:56:54 EST



Am 18.02.15 um 20:20 schrieb mehmet.coskun@gmail.com:
> I am writing a simple interpreter. I have managed to implement:
>
> Lexer
> Recursive descent parser
> Building AST


Any reason why you don't leave these steps to a tool like lex and yacc?
Would be much easier to enhance the language.


> Evaluating AST
>
> My interpreter can evaluate arithmetic expressions and boolean expressions.
>
> But I got stuck in implementing statements, code block, if and while statements.
> [...]
>
> Can you please help me to design if, while, statement and statement
> block functions? How can I implement this? What do I miss here in my
> implementation that caused me getting stuck without a working
> interpreter.


Writing an interpreter is generally easier than a compiler. You just
need to execute the commands in high-level language. Compound statements
generally work by recursive invocation of the interpreter on the blocks.
This is not much different from your Evaluate() function, which evals
the subexpressions recursively. Let's assume you have a Dispatch
function which switches on the NodeType and invokes a specialized
function to interpret it. Then an if would be somthing like (pseudocode)


proc if(condition, trueblock, falseblock) {
bool doit = Evaluate(condition);
if (doit) {
Dispatch(trueblock);
} else {
Dispatch(falsbelock);
}
}


It's really not much more than just writing out the if-then-else in the
implementation language (which is Pascal in your case, I assume) and
decorating execution blocks with Dispatch() and expression blocks with
Evaluate(). Of course, you need to enhance your Node structure such that
it can hold three elements, instead of only two. Or an arbitrary list of
arguments, which would come handy if you choose to implement n-ary
functions.


Of course, such a simplistic interpreter does not provide the more
advanced features in modern interpreters like stackless execution (for
coroutines) or fast execution (due to branching and function calls).
Exceptions are possible using return codes on the Dispatch function.


> Please note that I have to use data structures like linked list, tree
> and similars. But not object oriented or a more high level language.


Your choice, it should be possible - but you should add in a another
very handy data structure, namely associative arrays (hash tables).
Linked lists are certainly awkward to implement variable lookup.


Christian


Post a followup to this message

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