|[5 earlier articles]|
|Re: Interpreter design firstname.lastname@example.org (Sean Case) (2001-01-19)|
|Re: Interpreter design email@example.com (Venkatesha Murthy) (2001-01-19)|
|Re: Interpreter design firstname.lastname@example.org (Juan Carlos Gil Montoro) (2001-01-19)|
|Re: Interpreter design email@example.com (Laurent Guerby) (2001-01-19)|
|Re: Interpreter design firstname.lastname@example.org (2001-01-19)|
|Re: Interpreter design email@example.com (2001-01-20)|
|Re: Interpreter design firstname.lastname@example.org (2001-01-26)|
|Re: Interpreter design email@example.com (Steven D. Majewski) (2001-02-01)|
|From:||firstname.lastname@example.org (Norman Ramsey)|
|Date:||26 Jan 2001 16:45:30 -0500|
|Posted-Date:||26 Jan 2001 16:45:29 EST|
Laurent Guerby <email@example.com> wrote:
>I found "Programming Languages An Interpreter-Based Approach" by
>Samuel N. Kamin, Addison-Wesley, ISBN 0-201-06824-9 very interesting
>on this topic since it covers, imperative, functional, object and
>logic interpreters by "patching" a basic interpreter. Unfortunately it
>looks like it is out of print (I got mine from a used book sale).
I have been hard at work on a second edition. If you would like to
review a draft, please let me know.
I will point out that the interpreters work directly on the syntax of
the programs (concrete syntax in the 1st edition, abstract syntax in
the 2nd). This is a very good strategy for understanding the
semantics of the programming languages, which after all is the object
of the exercise. It is not such a great way to get the last ounce of
performance out of the interpreter, however. So, if you want to
experiment with language design, it might be a nice book to start
with. If you want to build *fast* interpreters, you should look
around for additional techniques.
Return to the
Search the comp.compilers archives again.