The next 700 programming languages
The Next 700 Programming Languages
P. J. Division of Corp., ,
Copyright By PowCoder代写 加微信 powcoder
” . . . t oday . . . 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. I n t r o d u c t i o n
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 at tempt to disentangle
these two aspects in some current languages.
This at tempt 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)
w h e r e x = b -4- 2c w h e r e 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 . T h e w h e r e – N o t a t i o n
In ordinary mathematical communication, these uses
of ‘ w h e r e ‘ require no explanation. Nor do the following:
f(b-l-2c) —I- f (2b–c)
w h e r e f (x) = x(x-t-a)
f(bA–2c) — f ( 2 b – c )
w h e r e f (x) = x (x+a)
a n d b = u / ( u + l )
a n d c = v/(v-t-1)
g ( f w h e r e f ( x ) = ax 2 -]- bx -I- c,
u / (u-4-1) ,
v / ( v + l ) )
w h e r e g ( f , p, q) = f ( p – k 2 q , 2 p – – q )
Volume 9 / Number 3 / March, 1966 C o m m u n i c a t i o n s o f t h e ACM 157
A phrase of the form ‘where definition’ will be called a
“where-clause.” An expression of the form ‘expression
where-clause’ is a “where-expression.” Its two principal
components are called, respectively, its “main clause”
and its “supporting definition.” To put ‘where ‘ into a
programming language the following questions need
Linguistic Structure. What structures of expression
can appropriately be qualified by a where-clause, e.g.,
conditional expressions, operand-listings, statements,
declarations, where-expressions?
Likewise, what structures of expression can appro-
priately be written as the right-hand side (rhs) of a
supporting definition? What contexts are appropriate for a
where-expression, e.g., as an arm of a conditional ex-
pression, an operator, the main-clause of a where-ex-
pression, the left-hand side (lhs) of a supporting definition,
the rhs of a supporting definition?
Syntax. Having answered the above questions, what
are the rules for writing the acceptable configurations
unambiguously? E.g., where are brackets optional or
obligatory? or other punctuation? or line breaks? or in-
dentation? Note the separation of decisions about struc-
ture from decisions about syntax. (This is not a denial
that language designers might iterate, like hardware
designers who distinguish levels of hardware design.)
Semantic Constraints on Linguistic Structure. In the
above examples each main clause was a numerical ex-
pression; i.e., given appropriate meanings for the various
identifiers in it, it denoted a number. What other kinds of
meaning are appropriate for a mainclause, e.g., arrays,
functions, structure descriptions, print-formats?
Likewise what kinds of meaning are appropriate for
rhs’s of supporting definitions? Notice there is not a third
question analogous to the third question above under
linguistic structure. This is because a where-expression
must mean the same kind of thing as its main clause and
hence raises no new question concerning what contexts
are meaningful. Notice also that the questions about
meaning are almost entirely independent of those about
structure. They depend on classifying expressions in two
ways that run across each other.
Outcome. What is the outcome of the more recondite
structural configurations among those deemed admissible,
e.g. mixed nests of where-expressions, function definitions,
conditional expressions, etc.?
Experimental programming has led the author to think
that there is no configuration, however unpromising it
might seem when judged cold, that will not turn up quite
naturally. Furthermore, some configurations of ‘where ‘
that might first appear to reflect somewhat pedantic dis-
tinctions, in fact provide close matches for current lan-
guage features such as n a m e / v a l u e and o w n (see [2, 3]).
All these questions are not answered in this paper. The
techniques for answering them are outlined in Section 4.
One other issue arises when ‘where ‘ is added to a
programming language–types and specifications. A
method of expressing these functionally is explained in
[2]. I t amounts to using named transfer-functions instead
of class names like in teger , i.e., writing
where n = round(n)
instead of the specification
Thus the use of functional notation does not jeopardize
the determination of type from textual evidence.
3. P h y s i c a l I S W I M a n d :Logical I S W I M
Like ALGOL 60, ISWIM has no prescribed physical
appearance. ALGOL C0’S designers sought to avoid commit-
ment to any particular sets of characters or type faces.
Accordingly they distinguish between “publication hm-
guage,” “reference language” and “hardware languages.”
Of these the reference language was the standard and was
used in the report itself whenever pieces of ALGOL 60
occurred. Publication and hardware languages are trans-
literations of the reference language, varying according to
the individual taste, needs and physical constraints on
available type faces and characters.
Such variations are different physical representations
of a single abstraction, whose most faithful physical
representation is the reference language. In describing
IswI~ we distinguish an abstract language called “logical
ISWIM,” whose texts are made up of “textual elements,”
characterized without commitment to a particular physical
representation. There is a physical representation suitable
for the medium of this report, and used for presenting
each piece of IswI~1 that occurs in this report. So this
physical representation corresponds to “reference ALGOL
60,” and is called “reference ISWIM,” or the “IswI~i
reference representation,” or the “IswI~,r reference hm-
To avoid imprecision one should never speak just of
“ISWIM,” but always of “logical IswxM” or of “such-
and-such physical ISWlM.” However, in loose speech,
where the precise intention is clear or unimportant, we
refer to “ISWlM” without quMifieation. We aim at a more
formal relation between physical and logical languages
than was the case in the ALGOL C0. This is necessary since
we wish to systematize and mechanize the use of different
physical representations.
4. F o u r L e v e l s o f A b s t r a c t i o n
The “physical~logical” terminology is often used to
distinguish features that are a fortuitous consequence of
physical conditions from features that are in some sense
more essential. This idea is carried further by making a
similar distinction among the “more essential” features.
In fact ISWlM is presented here as a four-level concept
comprising the following:
(1) physical IswlM’S, of which one is the reference
language and others are various publication and hardware
languages (not described here).
158 Communicat ions of the ACM Volt, me 9 / Number 3 / March, 1966
(2) logical ISWlM, which is uncommitted as to char-
acter sets and type faces, but committed as to the sequence
of textual elements, and the grammatical rules for group-
ing them, e.g., by parentheses, indentation and precedence
relations.
(3) abstract Iswls,,, which is uncommitted as to the
grammatical rules of sequence and grouping, but com-
mitted as to the grammatical categories and their nesting
structure. Thus abstract Iswis,~ is a “tree language” of
which logical IswlM is one linearization.
(4) applicative expressions (AEs), which constitute
another tree language, structurally more austere than
abstract ISWlM, and providing certain basic grammatical
categories in terms of which all of Isw1~’s more numerous
categories can be expressed.
The set of acceptable texts of :t physical ISWlM is
specified by the relations between 1 and 2, and between
2 and 3. The outcome of each text is specified by these
relations, together with a “frame of reference,” i.e., a rule
that associates a meaning with each of a chosen set of
identifiers.
These are the things that vary from one member of our
language family to the next. The specification of the family
is completed by the relation between abstract IswI~ and
AEs, together with an abstract machine that interpret
AEs. These elements are the same for all members of the
family and are not discussed in this paper (see [1, 2, 4]).
The relationship between physical ISWlM and logical
ISWIM is fixed by saying what physical texts represent
each logical element, and also what layout is permitted in
stringing them together. The relationship between logical
I s w ~ and abstract IswlM is fixed by a formal grammar
not unlike the one in the ALGOL 60 report, together with a
statement connecting the phrase categories with the
abstract grammatical categories.
These two relations cover what is usually called the
“syntax” or “grammar” of a language. In this paper
syntax is not discussed beyond a few general remarks and
a few examples whose meaning should be obvious.
The relationship between abstract Iswls( and AEs is
fixed by giving the form of AE equivalent to each abstract
IswiM grammatical category. I t happens that these latter
include a subset that exactly matches AEs. Hence this
link in our chain of reh~tions is roughly a mapping of
ISWIM into an essential “kernel” of IswIM, of which all the
rest is mere decoration.
5. A b s t r a c t I S W I M
The texts of abstract ISWlM are composite information
structures called amessage’s. The following structure
definition defines ~ the class amessage in terms of a class
called identifier. I t also defines several functions for
manipulating amessage’s. These comprise the predicates
2 Wri t ing a s t ruc tu re definition i~volves coining names for the
var ious a l te rna t ive fo rmats of amessage’s and their components .
The only obscure coinage is ” b e e t , ” which abbrev ia tes ” b e t a –
redex ,” i.e., ” an express ion amenable to rule (fl)”; see Section 7’.
demand, simple, infixed, etc; also the selectors body, rator,
leflarm, nee, etc; also (taking for granted certain un-
formalized conventions concerning structure definitions)
the constructors, consdemand, conscombination (elsewhere
~bbreviated to combine), consstandardade], etc. Examples
of reference IswI~ are given alongside, against the right
An amessage is
e i ther a demand, and has [ P r i n t a+2b
a body which is an aexprcss ion,
or e l se a definition, [Def x=a+2b
w h e r e r e c
an aexpress ion (aexp) is
e i ther simple, and has [CAth231″
a body which is an identifier
or a combination, in which case it has [sin(a+2b)
a rator, which is an aexp, or
and a rand, which is an aexp, a + 2b
or conditional, in which case it is
e i ther two-armed, and has [p–*a+2b; 2a–b
a condition, which is an aexp,
and a teftarm, which is an aexp,
and a rightarm, which is an aexp,
or one-armed, and has [q-+2a–b
a condition, which is an aexp,
and an arm, which is an aexp,
or a listing, and has [a+b, c+d, e+f
a body which is an aexp-l ist ,
or beet, and has [ x (x+ l ) w h e r e x = a + 2b
a mainclause, which is an aexp, or
and a support l e t x = a + 2b; x ( x + l )
which is an adef,
an adefinit ion (adef) is
e i ther standard, and has [x=a+2b
a definee (nee), which is an abe ,
and a definiens (niens), which is an aexp,
or functionform, arid has [f(x) = z ( x + l )
a lefthandside (lhs),
which is an abe- l i s t of length >2 ,
and a righthandside (rhs), which is an aexp
or programpoint, and has [ pp f (x ) = x ( x + l )
a body which is an adef,
or circular, and has [tee f ( n ) = ( n = 0 ) – + l ; n f ( n – 1 )
a body which is an adef,
or simultaneous, and has [x=a+2b a n d y=2a–b
a body, which is an adef-l ist ,
or beet, and has [f(y) = z ( x + y )
a mainclause, w h e r e x=a+2b
which is an adef,
and a support, which is an adef.
w h e r e an abe is
e i ther simple, and has
body, which is an identifier,
or e l se , is an abv-lislo. [x, (y, z), w
A program-point definition introduces a deviant kind
of function. Applying such a function precipitates pre-
mature termination of the where-expression containing
it, and causes its result to be delivered as the value of the
entire where-expression.
Program-points are Iswli ‘S, nearest thing to jumping.
Assignment is covered as a particular case of an operator.
For both of these the precise specification is in terms of the
underlying abstract machine (see [2]).
V o l u m e 9 / N u m b e r 3 / M a r c h , 1966 C o m m u n i c a t i o n s o f t h e ACM 159
6. R e l a t i o n s h i p to LISP
IswI~r can be looked on as an at tempt to deliver LisP
fronI its eponymous commitment to lists, its reputation
for hand-to-mouth storage allocation, the hardware
dependent flavor of its pedagogy, its heavy bracketing,
and its compromises with tradition. These five points are
now dealt with in turn:
(1) Iswi~ has no particular problem orientation.
Experiments so far have been mainly in numerical work
and language processing with brief excursions into “com-
mercial” programming and elsewhere. No bias towards or
away from a particular field of application has emerged.
(2) Outside a certain subset (corresponding closely to
ALGOL ~0 without dynamic own arrays), IswIM needs
garbage collection. An experimental prototype imple-
mentation followed common ALGOL 60 practice. I t used
dynamic storage allocation with two sources, one LIFO
and the other garbage collected, with the intention that
the LIFO source should take as big a share as possible.
However, as with ALGOL 60, there is a latent potential
for prealloeating storage in certain favorable and com-
monly useful situations. Compared with LISP the chief
amelioration of storage allocation comes out of a mere
syntactic difference, namely, the use of where (ol ‘let’
which is exactly equal in power and program structure).
This provides a block-structure not dissimilar in textual
appearance from ALGOL 60’S, though it slips off the pen
more easily, and is in many respects more generM.
(3) LisP has some dark corners, especially outside
“pure LISP,” in which both teachers and programmers
resort to talking about addresses and to drawing storage
diagrams. The abstract machine underlying IswI~,r is
aimed at illuminating these corners with a mininmm of
hardware dependence.
(4) The textual appearance of IswI~l is not like Lisp’s
S-expressions. I t is nearer to LISP’S M-expressions (which
constitute an informal language used as an intermediate
result in hand-preparing LISP programs). IswlAi has the
following additional features:
(a) “Auxiliary” definitions, indicated by ‘let’ or ‘where ‘ ,
with two decorations: ‘ and ‘ for simultaneous definitions,
and ‘rec’ for self-referential definitions (not to be mistaken
for a warning about recursive activation, which can of
course also arise from self-application, and without self-
reference).
(b) Infixed operators, incorporated systematically. A
logical ISWIM can be defined in terms of four unspecified
parameters: three subsets of the class of identifiers, for use
as prefixed, infixed and postfixed operators; and a prec-
edence relation defined over the union of these subsets.
(c) Indentation, used to indicate program structure. A
physical IswiM can be defined in terms of an unspecified
parameter: a subset of phrase c
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com