Related articles |
---|
What is an interpreter? tdarcos@mcimail.com (Paul Robinson) (1993-05-08) |
Re: What is an interpreter? prener@watson.ibm.com (1993-05-09) |
Re: What is an interpreter? haahr@adobe.com (1993-05-09) |
Re: What is an interpreter? monnier+@cs.cmu.edu (1993-05-10) |
Re: What is an interpreter? mleone+@cs.cmu.edu (1993-05-10) |
Re: What is an interpreter? macrakis@osf.org (1993-05-11) |
Re: What is an interpreter? khattra@cs.sfu.ca (1993-05-13) |
Newsgroups: | comp.compilers |
From: | haahr@adobe.com (Paul Haahr) |
Keywords: | interpreter, design |
Organization: | Adobe Systems Incorporated |
References: | 93-05-039 |
Date: | Sun, 9 May 1993 21:38:02 GMT |
Paul Robinson <tdarcos@mcimail.com> 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
criteria.
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
haahr@adobe.com ...!decwrl!adobe!haahr +1 415 962 6056
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.