Re: Writing an interpreter

Arne Evertsson <Arne.Evertsson@Octalogic.se> wrote:
>I am writing an interpreter for a pascal-like programming language. I have
>no previous experience of compiler/interpreter construction, so I am wondering


You a novice, too. Excellent, I'm a novice as well. Welcome to the club.


In my approach to an interpreter, I took a really unorthodox approach.
You played with flex/lex, right? It's got some great functionality for
scanning text. Yeah, you guessed it. I'm embedding an interpreter into flex.
Sounds weird, but it seems to be working. Doesn't save me from the hassle
of building trees or symbol tables, but at least I don't have to use
an endless sequence of strcmp()'s all over the place.


Flex's text scanning by regular expressions is really cool. I just set
the regular expressions to pick up what I want, and then for every
regular expression, I got a pre-defined behavior in response. Simple, heh?


Actually, I almost paniced and gave up at one point when I noticed that
flex only scanned forward. Yep, no jumps (requirement for any interpreter).
Or am I mistaken?


Seems flex has this one cool behavior where you can note the location of
scanning in the input stream. Every time I see a function call, I just
store the location in a table, and use ftell() to go to the location whenever
I want to.


As of now, I'm still in the beginning stages, but I'm wondering if
the great gurus of compilers would be kind enough to offer opinions on
my unorthodox approach of using flex. Will I fail? Will I succeed?
Is flex a standard tool in interpreter development, but I've been too
dense to figure it out?


Am I a scrub that should be kicked out of this newsgroup?
--
\\ Emcee Lam <>< \\ Electronics For Imaging (work)
\\ 28269 Peachtree Dr. \\ 2855 Campus Dr.
\\ Hayward, CA 94545 \\ San Mateo, CA 94403-2510
\\ 510/783-4154 \\ 415/286-8333 FAX: 415/286-8545
[That approach can certainly be made to work, but after a while you'll
probably find that you'll be happier translating to a tokenized internal
form, either trees and RPN, and interpreting that. It's considerably faster
when you don't have to rescan the source each time through a loop. -John]


--

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