Re: What is an interpreter? (Paul Haahr)
Sun, 9 May 1993 21:38:02 GMT

          From comp.compilers

Related articles
What is an interpreter? (Paul Robinson) (1993-05-08)
Re: What is an interpreter? (1993-05-09)
Re: What is an interpreter? (1993-05-09)
Re: What is an interpreter? (1993-05-10)
Re: What is an interpreter? (1993-05-10)
Re: What is an interpreter? (1993-05-11)
Re: What is an interpreter? (1993-05-13)
| List of all articles for this month |

Newsgroups: comp.compilers
From: (Paul Haahr)
Keywords: interpreter, design
Organization: Adobe Systems Incorporated
References: 93-05-039
Date: Sun, 9 May 1993 21:38:02 GMT

Paul Robinson <> writes:
> A question I'd like to pose to the readership with respect to either
> program generators or programmable applications. How do we determine when
> something is a "real" interpreter of a "real" language, and when it
> doesn't quite reach that point?

and then proposes the ability to do random access file I/O as a good
dividing line. The moderator suggests that Fortran 66, awk, and the
Bourne Shell would probably not count as ``real'' languages under that

I'd like to point readers of this list to Luca Cardelli's _Typeful
Programming_ (DEC SRC Report #45, May 1989) and his list of considerations
in designing a programming language in section 2.2, ``Theory and
Practice.'' In particular,

        /Generality/ A useful language (sometimes called a ``real'' language)
        should be able to support building a wide variety of systems. For this
        it should be both theoretically complete and practically complete.
        The former condition can be expressed as /Turing-completeness/: the
        ability of a language to express every computable function. The latter
        condition is harder to quantify, but here are some criteria which make
        a language more ``real.'' Practical completeness is the ability of a
        language to conveniently express its own (a) interpreter;
        (b) translator; (c) run-time support (e.g., garbage collection);
        (d) operating system. Of course this classification is very subjective,
        but in each case,a person claiming a given classification for a given
        system should be willing to make personal use of the resulting system.
        The language we describe [Quest] falls mainly in category (b), but we
        shall discuss how to extend it to category (c).

By this ``very subjective'' classification system, /bin/sh seems to fall
into category (a), awk in (b), and Fortran 66 in (c) or (d) if you allow a
little bit of assembly language assist.

My only criticism of this classification -- other than that I don't like
taxonomies in general, and certainly not where there are so many gray
areas -- is that is does not consider tasks outside of ``system
programming'' except as they resemble those listed. Nevertheless, it's
the best set of criteria I've seen.

PS: I strongly recommend _Typeful Programming_ to anyone interested in the
design of programming languages.
paul haahr adobe systems incorporated ...!decwrl!adobe!haahr +1 415 962 6056

Post a followup to this message

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