The Next 700 Programming Languages.pdf

瓦尔特

206

10页

0次

2021-02-21

50墨值下载

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.

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

Correspondence

between x and Church's X-notation. ''~

2. The where-Notation

In ordinary mathematical communication, these uses

'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

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

answers.

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

name/value and own

(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]. It amounts to using named transfer-functions instead

of class names like integer, i.e., writing

where

n = round(n)

instead of the specification

integer

Thus the use of functional notation does not jeopardize

the determination of type from textual evidence.

3. Physical ISWIM and :Logical ISWIM

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-

guage."

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. Four Levels of Abstraction

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 Communications of the ACM Volt, me 9 / Number 3 / March, 1966

of 10

50墨值下载

database

关注

评论