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.