Re: What is an interpreter?

haahr@adobe.com (Paul Haahr)
Sun, 9 May 1993 21:38:02 GMT

          From comp.compilers

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)
| List of all articles for this month |

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
--


Post a followup to this message

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