[plt-scheme] Industrial strength interpreters with Scheme?

From: Matthias Felleisen (matthias at ccs.neu.edu)
Date: Sat Nov 3 09:07:03 EDT 2007

On Nov 3, 2007, at 12:13 AM, Grant Rettke wrote:

> Lately I've been investigating books that use Scheme for implementing
> interpreters. As part of this investigation I've been reading comments
> on books that fall into this category,  and a common criticism is that
> a book "does not demonstrate how to implement \"real world\"
> interpreters, but only \"toy interpreters\"".
>
> Said comments of course do not point in the direction of books that do
> fulfill this aim, or elaborate on what makes interpreters \"real
> world\".
>
> What is your take on this? Are there books on this topic?

Noel and Prabhakar have given you a detailed answer but I'd like
to add something concerning the dismissive 'toy'. The very people
who have tried to use 'toy' in my presence are incapable of
writing one of those interpreters. They are incapable of following
the systematic derivation of a register-machine based interpreter
in EOPL not to speak of executing one themselves. They cannot
appreciate that such machines/interpreters are written in
"parenthesized" C and that writing them in C gives you 80%
of the performance that industrial strength interpreters get
and that they never reach.

These people "throw" together interpreters via trial and
error. Based on reg expressions and some BNF knowledge and
reading around in other interpreters. They wouldn't be able
to convey the knowledge and they have an incredibly hard
time adding constructs that are beyond their scope of
understanding -- because they can't design an interpreter
and then derive a fast one. To wit:

  -- lambda in Python
  -- continuations in Stackless Python
  -- blocks in Perl

Just study the history of such constructs and see how long it
took them to get them right.

Of course, you will also find excuses such as "we don't really
need lambda" (except that everyone knows you do want them to
write callbacks for example) and "it's for efficiency" (except
that once they implemented them with the proper semantics,
these things were faster).

Deep down these people are incompetent and they know it and their
fear of revealing this makes them use such words without any
backup.

If you condemn something, know it. Know it well. -- Matthias






Posted on the users mailing list.