Re: Example interpreter C

George Neuner <>
24 Aug 2005 18:14:23 -0400

          From comp.compilers

Related articles
Example interpreter C (Henry Butwsky) (2005-08-13)
Re: Example interpreter C (Laurence Finston) (2005-08-16)
Re: Example interpreter C (Rafael 'Dido' Sevilla) (2005-08-16)
Re: Example interpreter C (2005-08-21)
Re: Example interpreter C (Laurence Finston) (2005-08-21)
Re: Example interpreter C (George Neuner) (2005-08-24)
Re: Example interpreter C (2005-08-24)
Re: Example interpreter C (Julian Stecklina) (2005-08-31)
Re: Example interpreter C (Joerg Simon) (2005-09-02)
Re: Example interpreter C (Laurence Finston) (2005-09-07)
Re: Example interpreter C (Ivan Boldyrev) (2005-09-10)
Re: Example interpreter C (George Neuner) (2005-09-10)
[4 later articles]
| List of all articles for this month |

From: George Neuner <>
Newsgroups: comp.compilers
Date: 24 Aug 2005 18:14:23 -0400
Organization: Compilers Central
References: 05-08-055 05-08-062 05-08-073
Keywords: interpreter, practice
Posted-Date: 24 Aug 2005 18:14:23 EDT

On 21 Aug 2005 00:21:14 -0400, Laurence Finston <>

>I'm sure a knowledge of compiler theory would make me a better programmer,

Creating languages usually isn't about formal grammars and building
interpreters for code. Most of programming is about reducing the
semantic level between the problem and the solution - ie. the code.
You rarely can bring the problem down to the computer's level, mostly
you have to bring the computer up to the problem. When you create a
set of functions that let you think about solving the problem in it's
own terms you are creating a domain specific language in which to
solve the problem - the fact that the language you create might not be
visible to a user of your application is not really relevent.

But more important, I think, is the practical experience of compiler
implementation. Compilers are complex programs that intersect many
skill areas. As a developer you will certainly need to successfully
parse input, format output, manipulate complex data structures, manage
memory and schedule operations. Even a simple compiler touches all of
these things and more.

>however I didn't need it to implement loops and conditionals. If they
>require an Abstract Syntax Tree, then I must have implemented one without
>knowing it.

It depends. There is often no need to create any kind of alternate
representation of the code. It is quite easy to directly interpret
many languages from source using the interpreter itself to keep track
of the execution environment.

However, a lot of interpreters are actually hybrids which first do
some compilation to an intermediate form (ASTs are one such form) and
then interpret the intermediate form. The compile steps catch errors
and, optionally, perform some optimization. The interpreter then
works with canonical program form rather than the source text. This
both simplifies the interpreter code and allows it to be physically
separate from the code that produces the intermediate form.

[I strongly agree with this last part. It's much easier and faster to interpret
RPN strings or ASTs where you know it's at least syntactically correct. -John]

Post a followup to this message

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