What is an interpreter?

Paul Robinson <tdarcos@mcimail.com>
Sat, 8 May 1993 15:20:06 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)
When should software applications be programmable? ipser@solomon.technet.sg (1993-05-13)
[2 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: Paul Robinson <tdarcos@mcimail.com>
Keywords: interpreter, comment
Organization: Tansin A. Darcos & Company, Silver Spring, MD USA
Date: Sat, 8 May 1993 15:20:06 GMT

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?

Is DBASE III a "real" interpreter? No question that it is. Is Lotus
1-2-3's macro language sufficient to qualify? Maybe. (Using the
qualification below, it doesn't.)

Here's the reason why: at what point does a programmable application cross
over from just a means to assist the application in doing whatever it
primarily does, and becomes a programming language in and of itself?

If you have an adventure game engine which has a programming language such
that it can be programmed do add features, the possible point would be if
an application without the adventure features, for example, to do a
calculation or to scan a file, can be created using the language.

File I/O, I think is the knife that cuts the "toys" from the "real"
languages. Programmable interpreters that support random-access file I/O
and the ability to read and write random records, stop being toys and
become real programming languages. I think this, more than anything else,
represents the touchstone which may be used to identify when and where the
two classes may be differentiated.
[Hmmn, that rules out most implementations of Fortran-66, awk, and the
Bourne shell. -John]

Post a followup to this message

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