|What is an interpreter? firstname.lastname@example.org (Paul Robinson) (1993-05-08)|
|Re: What is an interpreter? email@example.com (1993-05-09)|
|Re: What is an interpreter? firstname.lastname@example.org (1993-05-09)|
|Re: What is an interpreter? email@example.com (1993-05-10)|
|Re: What is an interpreter? firstname.lastname@example.org (1993-05-10)|
|Re: What is an interpreter? email@example.com (1993-05-11)|
|Re: What is an interpreter? firstname.lastname@example.org (1993-05-13)|
|From:||email@example.com (Paul Haahr)|
|Organization:||Adobe Systems Incorporated|
|Date:||Sun, 9 May 1993 21:38:02 GMT|
Paul Robinson <firstname.lastname@example.org> 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
email@example.com ...!decwrl!adobe!haahr +1 415 962 6056
Return to the
Search the comp.compilers archives again.