The Next 700 Programming Languages
P. J. Landin
Univac Division of Sperry Rand Corp., New York, New York
"...
today... 1,700 special programming languages used to 'com-
municate' in over 700 application areas."--Computer
Software
Issues,
an American Mathematical Association Prospectus, July 1965.
A family of unimplemented computing languages is de-
scribed that is intended to span differences of application area
by a unified framework. This framework dictates the rules
ckout the uses of user-coined names, and the conventions
about characterizing functional relationships. Within 'lhis frame-
work 'lhe design of a specific language splits into two inde-
pendent parts. One is 'lhe choice of written appearances of
programs (or more generally, their physical representation).
The o:her is the choice of the abstract entities (such as numbers,
character-strings, lists of them, functional relations among
them) that can be referred to in the language.
The system is biased towards "expressions" rather than
"statements." It includes a nonprocedural (purely functional)
subsystem fhat aims to expand the class of users' needs that
can be met by a single print-instruction, without sacrificing the
important properties that make conventional right-hand-side
expressions easy to construct and understand.
1.
Introduction
Most programming languages are partly a way of
expressing things in terms of other things and partly a
basic set of given things. The Isw~M (If you See What I
Mean) system is a byproduct of an attempt to disentangle
these two aspects in some current languages.
This attempt has led the author to think that many
linguistic idiosyneracies are concerned with the former
rather than the latter, whereas aptitude for a particular
class of tasks is essentially determined by the latter rather
than the former. The conclusion follows that many
language characteristics are irrelevant to the alleged
problem orientation.
IswI~ is an attempt at a general purpose system for
describing things in terms of other things, that can be
problem-oriented by appropriate choice of "primitives."
So it is not a language so much as a family of languages,
of which each member is the result of choosing a set of
primitives. The possibilities concerning this set and what
is needed to specify such a set are discussed below.
Isw~M is not alone in being a family, even after mere
syntactic variations have been discounted (see Section 4).
In practice, this is true of most languages that achieve
more than one implementation, and if the dialects are well
disciplined, they might with luck be characterized as
Presented at an ACM Programming Languages and Pragmatics
Conference, San Dimes, California, August 1965.
1 Throe is no more use or mentiol~ of X in this paper--eognoseenti
will nevertheless sense an undercurrent. A not inappropriate title
would have been "Church without lambda,"
differences in the set of things provided by the library or
operating system. Perhaps had ALGOL 60 been launched
as a family instead of proclaimed as a language, it would
have fielded some of the less relevant criticisms of its
deficiencies.
At first sight the facilities provided in IswI~,~ will appear
comparatively meager. This appearance will be especially
misleading to someone who has not appreciated how much
of current manuals are devoted to the explanation of
common (i.e., problem-orientation independent) logical
structure rather than problem-oriented specialties. For
example, in almost every language a user can coin names,
obeying certain rules about the contexts in which the
name is used and their relation to the textual segments
that introduce, define, declare, or otherwise constrain its
use. These rules vary considerably from one language to
another, and frequently even within a single language
there may be different conventions for different classes of
names, with near-analogies that come irritatingly close to
being exact. (Note that restrictions on what names can
be coined also vary, but these are trivial differences. When
they have any logical significance it is likely to be perni-
cious, by leading to puns such as ALaOL'S integer labels.)
So rules about user-coined names is an area in which
we might expect to see the history of computer applica-
tions give ground to their logic. Another such area is in
specifying functional relations. In fact these two areas are
closely related since any use of a user-coined name im-
plicitly involves a functional relation; e.g., compare
x(x-ka) f(b+2c)
where x = b -4- 2c where
f(x) = x(x+a)
ISW~M is thus part. programming language and part pro-
gram for research. A possible first step in the research
program is 1700 doctoral theses called
"A
Correspondence
between x and Church's X-notation. ''~
2. The where-Notation
In ordinary mathematical communication, these uses
of
'where'
require no explanation. Nor do the following:
f(b-l-2c) ---I- f(2b--c)
where
f(x) = x(x-t-a)
f(bA--2c) -- f(2b-c)
where
f(x) = x(x+a)
and b =
u/(u+l)
and c =
v/(v-t-1)
g(f
where
f(x) = ax 2 -]- bx -I- c,
u/(u-4-1),
v/(v+l))
where
g(f, p, q) = f(p-k2q, 2p--q)
Volume 9 / Number 3 / March, 1966
Communications of the
ACM 157