Re: Looking for a book with emphasis on interpreters

eac@iexist.att.com writes:
>What I am wondering about is why there has been so little written of late
>on the topic of interpreters. Do people feel that we have learned all that
>can be learned/invented on this topic? If so, then I would have thought
>that we would have seen someone's attempt at the definitive book on
>interpreter technologies published by now.


There's a PhD student here by the name of Jason Thai who is working on a
system for Constraint Logic Programming. Think of a logical theory split
into two parts: a "constraint" sublanguage and a "program" language,
where sound algorithms are known for solving problems expressed in the
"constraint" sublanguage. You can think of the program as dynamically
(incrementally) constructing a network of constraints, and the constraint
engine as incrementally reporting its deductions to the program. Prolog
is a trivial constraint logic programming language: the constraint
sublanguage is the theory of equality, and the constraint solver is the
unification algorithm. CLP is a very nice idea: it increases the power
of Prolog by making it _more_ logical, not less, yet it also lets you
plug into traditional things like the Simplex algorithm (when appropriate).
The data flow of CLP languages is rather hard to predict, and it is very
common for CLP languages to support (automatic, implicit) "coroutining",
which has a lot in common with lazy execution of functional languages, so
the control flow is not as obvious as it might be either. Jason Thai had
the idea that these languages are _better_ implemented by interpreters than
compilers. He currently has a hand-written interpreter (in a SPARC and a
486 version) that runs Prolog code at about 1/3rd the speed of native machine
code produced by a well-accepted Prolog compiler. (This is code _not_
exploiting coroutining or constraints.)


There are some very smart people working on techniques for compiling CLP
languages. I don't think there's any doubt that for any given CLP language
it will be possible to do better with a compiler than an interpreter. But
there are many many constraint sublanguages to investigate, and even more
algorithms one might consider for the constraint solvers. An interpreter-
based approach looks as though it will be easier to extend a CLP language
with alternative/additional types of constraints/solvers.


I'm sure there is still a _lot_ to learn about interpreters. For example,
one technique that is much discussed in the declarative language community
is partial execution: take your interpreter and automatically specialise
it for a particular input (program). We've still got a lot to learn about
how to write interpreters that work well when used _that_ way.
--

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