Technical University Delft Delft, Holland W. L. van der Poel, (Chairman of Working Group 2.1 on Algol of the International Federation for Information Processing)
The original report is well worth study and can be found at the Museum of RetroComputing //locke.ccil.org/pub/retro/retromuseum.html The original BNF is defined in [ BNF in comp.text.Meta ]
Special Algol 60 Symbols
Translating the Algol 60 Report into MATHS is made difficult because Algol 60
preceeded ASCII (and indeed influenced it a little). Algol 60 programs are
made up of basic symbols - some represented by words in a special typeface
and some by special symbols in a specially designed font. I have
included Erik Schoenfelder LaTeX descriptions of these below.
The basic symbols that were printed like words where actually single symbols, not identifiers! In Algol60 a variable could be called "do" and not be confused with the basic symbol printed with the letters "d" and "o" in bold case. This caused implementers a hard time.
I have just used the word in examples. In this file I have taken the liberty of transcribing a basic symbol into a string like this: S(w) where word describes the basic symbol inside syntax descriptions.
I have also replaced the symbols in the special type face by their some ASCII Symbol with a related meaning...
In short: This file is the syntax of an implementation of Algol in ASCII not the original reference language. [ comp.text.ASCII.html ]
"\/"::= logical or.::=TeX({\(∨\)}).
"/\"::= logical and.::=TeX({\(∧\)}).
J.W. Backus, F.L. Bauer, J.Green, C. Katz, J. McCarthy
P. Naur, A.J. Perlis, H. Rutishauser, K. Samuelson, B. Vauquois
J.H. Wegstein, A. van Wijngaarden, M. Woodger
Peter Naur
Dedicated to the memory of William Turanski
. . . . . . . . . ( end of section Introduction,) <<Contents | End>>
Description
As with the preliminary Algol report, three different levels of language are recognized, namely a Reference Language, a Publication Language, and several Hardware Representations.
It is the working language of the committee.
It is the defining language.
The characters are determined by ease of mutual understanding and not by any computer limitations, coders notation, or pure mathematical notation.
It is the basic reference and guide for compiler builders.
It is the guide for all hardware representations.
It is the guide for transliterating from publication language to any locally appropriate hardware representations.
The main publications of the Algol language itself will use the reference representation.
The publication language admits variations of the reference language according to usage of printing and handwriting (e.g. subscripts, spaces, exponents, Greek letters).
It is used for stating and communicating process.
The characters used may be different in different countries, but univocal correspondence with reference representation must be secured.
Each of these is a condensation of the reference language enforced by the limited number of characters on the standard input equipment.
Each one of these uses the character set of a particular computer and is the language accepted by a translator for that computer.
Each of these must by accompanied by a special set of rules for transliterating from publication or reference language.
For transliteration between the reference language and a language suitable for publications, among others, the following rules are recommended.
Reference Language Publication Language
Subscript brackets [ ] Lowering of the line between the
brackets and removal of the brackets.
Exponentiation ^ Raising the exponent.
Parentheses () Any form of parentheses, brackets,
braces.
Basis of ten \ten Raising of the ten and of the following
integral number, inserting of the
intended multiplication sign.
Description of the reference language
Was sich ueberhaupt sagen laesst, laesst sich
klar sagen; und wovon man nicht reden
kann, darueber muss man schweigen.
Ludwig Wittgenstein
As stated in the introduction, the algorithmic language has three different kinds of representations -- reference, hardware, and publication -- and the development described in the sequel is in terms of the language are represented by a given set of symbols -- and it is only in the choice of symbols that the other two representations may differ. Structure and content must be the same for all representations.
The purpose of the algorithmic language is to describe computational processes. The basic concept used for the description of calculating rules is the well known arithmetic expression containing as constituents numbers, variables, and functions. From such expressions are compounded, by applying rules of arithmetic composition, self-contained units of the language -- explicit formulae -- called assignment statements.
To show the flow of computational processes, certain non-arithmetic statements and statement clauses are added which may describe e.g., alternatives, or iterative repetitions of computing statements. Since it is necessary for the function of the statements that one statement refers to another, statements may be provided with labels. A sequence of statements may be enclosed between the statement brackets S("begin") and S("end") to form a compound statement.
Statements are supported by declarations which are not themselves computing instructions, but inform the translator of the existence and certain properties of objects appearing in statements, such as the class of numbers taken on as values by a variable, the dimension of an array of numbers, or even the set of rules defining a function. A sequence of declarations followed by a sequence of statements and enclosed between S("begin") and S("end") constitutes a block. Every declaration appears in a block in this way and is valid only for that block.
A program is a block or compound statement which is not contained within another statement and which makes no use of other statements not contained within it.
In the sequel the syntax and semantics of the language will be given [ Foot note 1] .
Foot note 1
Whenever the precision of arithmetic is stated as being in general
not specified, or the outcome of a certain process is left undefined
or said to be undefined, this is to be interpreted in the sense that
a program only fully defines a computational process if the
accompanying information specifies the precision assumed, the kind
of arithmetic assumed, and the course of action to be taken in all
such cases as may occur during the execution of the computation.
. . . . . . . . . ( end of section 1.) <<Contents | End>>
2. Basic symbols, identifiers, numbers, and strings.
Basic concepts
The reference language is built up from the following basic symbols:
This alphabet may be arbitrarily restricted, or extended with any other distinctive character (i.e. character not coinciding with any digit, logical value or delimiter).
Letters do not have individual meaning. They are used for forming identifiers and strings [ Foot note 2 ] (cf. sections [ 2.4. Identifiers ] , [ 2.6. Strings ] ).
Foot note 2
It should be particularly noted that throughout the reference
language underlining [here this looks like S("underlined") - (botting) is used for defining independent basic symbols (see
sections 2.2.2 and 2.3). These are understood to have no relation to
the individual letters of which they are composed. Within the
present report underlining will be used for no other purposes.
2.2.1 Digits.
Digits are used for forming numbers, identifiers, and strings.
2.2.2 Logical values.
The logical values have a fixed obvious meaning.
Delimiters have a fixed meaning which for the most part is obvious or else will be given at the appropriate place in the sequel.
Layout
Typographical features such as blank space or change to a new line
have no significance in the reference language. They, however, be used
freely for facilitating reading.
Comments
For the purpose of including text among the symbols of a program the
following "comment" conventions hold:
By equality is here meant that any of the structures shown on the left hand side may be replaced, in any occurrence outside of strings, by the symbol shown on the right hand side without any effect on the action of the program. It is further understood that the comment structure encountered first in the text when reading from left to right has precedence in being replaced over later structures contained in the sequence.
q
Soup
V17a
a34kTMNs
MARILYN
The same identifiers cannot be used to denote two different quantities except when these quantities have disjoint scopes as defined by the declarations of the program (cf section 2.7. Quantities, kinds and scopes and section 5. Declarations).
. . . . . . . . . ( end of section 2.4) <<Contents | End>>
2.5. Numbers
0 -200.084 -.083\ten -02
177 + 07.43\ten 8 -\ten 7
.5384 9.34\ten +10 \ten -4
+0.7300 2\ten -4 +\ten +5
2.5.3. Semantics.
Decimal numbers have their conventional meaning.
The exponent part is scale factor expressed as an integral power of 10.
2.5.4. Types.
Integers are of the type S("integer"). All other
numbers are of type S("real") (cf. section 5.1 Type declarations).
. . . . . . . . . ( end of section 2.5) <<Contents | End>>
2.6. Strings
`5k,,-`[[[` /\ =/:'Tt''
`This|_|is|_|a|_|`string''
2.6.3. Semantics.
In order to enable the language to handle arbitrary
sequences of basic symbols the string quotes "`" and "'" are introduced.
The Symbol |_| denotes a space. It has no significance outside strings.
Strings are used as actual parameters of procedures (cf. sections 3.2.
Function designators and 4.7. Procedure Statements).
. . . . . . . . . ( end of section 2.6) <<Contents | End>>
2.7. Quantities, kinds and scopes
The scope of a quantity is the set of statements and expressions in which the declaration of the identifier associated with that quantity is valid. For labels see section 4.1.3.
. . . . . . . . . ( end of section 2.7) <<Contents | End>>
2.8. Values and types
Certain of the syntactic units are said to possess values. These values will in general change during the execution of the program The values of expressions and their constituents are defined in section 3. The value of an array identifier is the ordered set of values of the corresponding array of subscripted variables (cf. section 3.1.4.1).
The various types'' (S("integer"), S("real"), S("Boolean")) basically denote properties of values. The types associated with syntactic units refer to the values of these units.
. . . . . . . . . ( end of section 2) <<Contents | End>>
3. Expressions
epsilon
detA
a17
Q[7,2]
x[sin(n * pi/2),Q[3,n,4]]
3.1.4.2.
Each subscript position acts like a variable of type
S("integer") and the evaluation of the subscript is understood to be
equivalent to an assignment to this fictitious variable (cf. section
4.2.4). The value of the subscripted variable is defined only if the
value of the subscript expression is within the subscript bounds of the
array (cf. section 5.2. Array declarations).
. . . . . . . . . ( end of section 3.1.4. Subscripts.) <<Contents | End>>
. . . . . . . . . ( end of section 3.1) <<Contents | End>>
3.2. Function designators
sin(a-b)
J(v+s,n)
R
S(s-5) Temperature: (T) Pressure: (P)
Compile (`:=') Stack: (Q)
3.2.3. Semantics.
Function designators define single numerical or
logical values which result through the application of given sets of
rules defined by a procedure declaration (cf. section 5.4. Procedure
declarations) to fixed sets of actual parameters. The rules governing
specification of actual parameters are given in section 4.7. Procedure
statements. Not every procedure declaration defines the value of a
function designator.
3.2.4. Standard functions.
Certain identifiers should be reserved for
the standard functions of analysis, which will be expressed as
procedures. It is recommended that this reserved list should contain:
These functions are all understood to operate indifferently on arguments both of type S("real") and S("integer"). They will all yield values of type S("real"), except for sign (E) which will have values of type S("integer"). In a particular representation these function may be available without explicit declarations (cf. section 5. Declarations).
3.2.5. Transfer functions.
It is understood that transfer functions
between any pair of quantities and expressions my be defined. Among the
standard functions it is recommended that there be one, namely
entier (E),
which transfers'' an expression of real type to one of integer type, and assigns to it the value which is the largest integer not greater than the value of E.
. . . . . . . . . ( end of section 3.2) <<Contents | End>>
3.3. Arithmetic expressions
Primaries:
7.394\ten -8
sum
w[i+2,8]
cos(y+z * 3)
(a-3/y+vu ^ 8)
Factors:
omega
sum ^ cos(y+z * 3)
7.394\ten -8 ^ w[i+2,8] ^ (a-3/y+vu ^ 8)
Terms:
U
omega * sum ^ cos(y+z * 3)/7.394\ten -8 ^ w[i+2,8] ^ (a-3/y+vu ^ 8)
Simple arithmetic expressions:
U-Yu+omega * sum ^ cos(y+z * 3)/7.394\ten -8 ^ w[i+2,8] ^ (a-3/y+vu ^ 8)
Arithmetic expressions:
w * u-Q(S+Cu) ^ 2
if q < 0 then S+3 * Q/A else 2 * S+3 * q
if a < 0 then U+V else if a * b < 17 then U/V else if k <> y then V/U else 0
a * sin(omega * t)
0.57\ten 12 * a[N * (N-1)/2,0]
(A * arctan(y)+Z) ^ (7+Q)
if q then n-1 else n
if a < 0 then A/B else if b=0 then B/A else z
In the more general arithmetic expression, which include if clauses, one out of several simple arithmetic expressions is selected on the basis of the actual values of the Boolean expression (cf. section 3.4. Boolean expressions). This selection is made as follows: The Boolean expressions of the if clauses are evaluated one by one in the sequence from left to right until one having the value S("true") is found. The value of the arithmetic expression is then the value of the first arithmetic expression following this Boolean (the largest arithmetic expression found in this position is understood). The construction:
S("else") simple_arithmetic_expression
is equivalent to the construction:
S("else") S("if") S("true") S("then") simple_arithmetic_expression
3.3.4.1.
The operators +, -, and * have the conventional meaning
(addition, subtraction, and multiplication). The type of the expression
will by S("integer") if both of the operands are of S("integer")
type, otherwise S("real").
In addition, subtraction, and multiplication, the type of the expression will by S("integer") if both of the operands are of S("integer") type, otherwise S("real").
3.3.4.2.
The operations term / factor and term
% factor both denote division, to be understood as a
multiplication of the term by the reciprocal of the factor with due
regard to the rules of precedence (cf. section 3.3.5). Thus for
example a/b*7/(p-q)*v/s
means ((((a*(b^-1))*7)*((p-q)^-1))*v)*(s^-1)
The operator / is defined for all four combinations of types S("real") and S("integer") and will yield results of S("real") type in any case. The operator % is defined only for two operands of type S("integer") and will yield a result of type S("integer"), mathematically defined as follows: .
Compare with sections 3.2.4 and 3.2.5.
3.3.4.3.
The operation factor ^ factor
denotes exponentiation, where the factor is the base and the primary is
the exponent. Thus for example 2 ^ n ^ k means (2^n)^k
while 2 ^ (n ^ m) means 2^(n^m).
Writing i for a number of S("integer") type, r for a number of S("real") type, and a for a number of ether S("integer") or S("real") type, the result is given by the following rules: .
a ^ i
if i>0: a*a*...*a (i times), of the same type as a.
if i=0: if a<>0: 1, of the same type as a.
if a=0: undefined.
if i<0, if a<>0: 1/(a*a*a*...*a) (the denominator has
-i factors), of type S("real").
if a=0: undefined.
a ^ r
if a>0: exp(r*ln(a)), of type S("real").
if a=0, if r>0: 0.0, of type S("real").
if r<=0: undefined.
if a<0: always undefined.
. . . . . . . . . ( end of section 3.3.4. Operators and types.) <<Contents | End>>
3.3.5. Precedence of operators.
The sequence of operations within one
expression is generally from left to right, with the following
additional rules:
3.3.5.1.
According to the syntax given in section 3.3.1 the following
rules of precedence hold:
first: ^
second: * / %
third: + -
3.3.5.2.
The expression between a left parenthesis and the matching
right parenthesis is evaluated by itself and this value is used in
subsequent calculations. Censequently the desired order of execution of
operations within an expression can always be arranged by appropriate
positioning of parenthesis. .
3.3.6.
Arithmetics of S("real") quantities. Numbers and variables of
type S("real") must be interpreted in the sense of numerical analysis,
i.e. as entities defined inherently with only a finite accuracy.
Similarly, the possibility of the occurrence of a finite deviation from
the mathematically defined result in any arithmetic expression is
explicitly understood. No exact arithmetic will be specified, however,
and it is indeed understood that different hardware representations may
evaluate arithmetic expressions differently. The control of the
possible consequences of such differences must be carried out by the
methods of numerical analysis. This control must be considered a part
of the process to be described, and will therefore be expressed in terms
of the language itself. .
. . . . . . . . . ( end of section 3.3) <<Contents | End>>
3.4. Boolean expressions
x=-2
Y>V\/z<q
a+b>-5/\z-d>q^2
p/\q\/x<>y
g==~a/\b/\~c\/d\/e=>/\ f
if k<1 then s<w else h <= c
if if if a then b else c then d else f then g else h < k
3.4.3. Semantics.
A Boolean expression is a rule for computing a
logical value. The principles of evaluation are entirely analogous to
those given for arithmetic expressions in section 3.3.3.
3.4.4. Types.
Variables and function designators entered as Boolean
primaries must be declared S("Boolean") (cf. section 5.1. Type
declarations and section 5.4.4. Value of function designators).
3.4.5. The operators.
Relations take on the value S("true") whenever
the corresponding relation is satisfied for the expressions involved,
otherwise S("false").
The meaning of the logical operators /\ (not), /\ (and), \/ (or), => (implies), and == (equivalent), is given by the following function table.
b1 | false | false | true | true
b2 | false | true | false | true
----------------------------------------------------------------
/\ b1 | true | true | false | false
b1 /\ b2 | false | false | false | true
b1 \/ b2 | false | true | true | true
b1 => b2 | true | true | false | true
b1 == b2 | true | false | false | true
first: arithmetic expressions according to section 3.3.5.
second: < <= = >= > <>
third: /\
fourth: /\
fifth: \/
sixth: =>
seventh: ==
3.4.6.2.
The use of parentheses will be interpreted in the sense given
in section 3.3.5.2.
. . . . . . . . . ( end of section 3.4.6. Precedence of operators.) <<Contents | End>>
. . . . . . . . . ( end of section 3.4) <<Contents | End>>
3.5. Designational expressions
17
p9
Coose[n-1]
Town [if y<0 then N else N+1]
if Ab<c then 17 else q[if w <= 0 then 2 else n]
. . . . . . . . . ( end of section 3) <<Contents | End>>
4. Statements
In order to make it possible to define a specific dynamic succession, statements may be provided with labels.
Since sequences of statements may be grouped together into compound
statements and blocks the definition of statement must necessarily be
recursive. Also since declarations, described in section 5, enter
fundamentally into the syntactic structure, the syntactic definition of
statements must suppose declarations to be already defined.
4.1. Compound statements and blocks
This syntax may be illustrated as follows: Denoting arbitrary statements, declarations, and labels, by the letters S, D, L, respectively, the basic syntactic units take the forms:
Compound statement:
L:L: ... begin S; S; ... S; S end
Block:
L:L: ... begin D; D; .. D; S; S; ... S; S end
It should by kept in mind that each of the statements S may again be a
complete compound statement or a block.
4.1.2. Examples.
a:=p+q
goto Naples
Start: Continue: W:=7.993
begin x:=0; for y:=1 step 1 until n do x:=x+A[y];
if x>q then goto STOP else if x>w-2 then goto S;
Aw: St: W:=x+bob end
Q: begin integer i, k; real w;
for i:=1 step 1 until m do
for k:=i+1 step 1 until m do
begin w:=A[i,k];
A[i,k]:=A[k,i];
A[k,i]:=w end for i and k
end block Q
. . . . . . . . . ( end of section 4.1.2. Examples.) <<Contents | End>>
4.1.3. Semantics.
Every block automatically introduces a new level of
nomenclature. This is realized as follows: Any identifier occurring
within the block my through a suitable declaration (cf. section
[ 5. Declarations ]
) be specified to be local to the block in question. This
means (a) that the entity represented by this identifier inside the
blocks has no existence outside it and (b) that any entity represented
by this identifier outside the block is completely inaccessible inside
the block.
Identifiers (except those representing labels) occurring within a block and not being declared to this block will be non-local to it, i.e. will represent the same entity inside the block and in the level immediately outside it. A label separated by a colon from a statement, i.e. labelling that statement, behaves as though declared in the head of the smallest embracing block, i.e. the smallest block whose brackets S("begin") and S("end") enclose that statement. In this context a procedure body must be considered as if it were enclosed by S("begin") and S("end") and treated as a block.
Since a statement of a block may again itself be a block the concepts local and non-local to a block must be understood recursively. Thus an identifier, which is non-local to a block A, may or may not be non-local to the block B in which A is one statement.
. . . . . . . . . ( end of section 4.1) <<Contents | End>>
4.2. Assignment statements
s:=p[0]:=n:=n+1+s
n:=n+1
A:=B/C-v-q*S
S[v,k+2]:=3-arctan(s*zeta)
V:=Q>Y/\Z
4.2.3.1.
Any subscript expression occurring in the left part variables
are evaluated in sequence from left to right.
4.2.3.2.
The expression of the statement is evaluated.
4.2.3.3.
The value of the expression is assigned to all the left part
variables, with any subscript expressions having values as evaluated in
step 4.2.3.1.
. . . . . . . . . ( end of section 4.2.3. Semantics.) <<Contents | End>>
4.2.4. Types.
The type associated with all variables and procedure
identifiers of a left part list must be the same. If the type is
S("Boolean"), the expression must likewise be S("Boolean"). If the
type is S("real") or S("integer"), the expression must be
arithmetic. If the type of the arithmetic expression differs from that
associated with the variables and procedure identifiers, appropriate
transfer functions are understood to be automatically invoked. For
transfer from S("real") to S("integer") type the transfer function
is understood to yield a result equivalent to entier(E+0.5)
where E is the value of the expression. The type associated with a
procedure identifier is given by the declarator which appears as the
first symbol of the corresponding procedure declaration (cf. section
5.4.4).
. . . . . . . . . ( end of section 4.2) <<Contents | End>>
4.3. Go to statements
goto 8
goto exit [n+1]
goto Town [ if y<0 then N else N+1]
goto if Ab<c then 17 else q [ if w\mlt0 then 2 else n]
. . . . . . . . . ( end of section 4.3) <<Contents | End>>
4.4. Dummy statements
L:
begin ....; John: end
. . . . . . . . . ( end of section 4.4) <<Contents | End>>
4.5. Conditional statements
if x>0 then n:=n+1
if s>u then V: q:=n+m else goto R
if s<0 \/ P<=Q then AA: begin if q\mltv then a:=v/s
else y:=2*a end else if v>s then a:=v-q
else if v>s-1 then goto S
4.5.3.1. If statement.
The unconditional statement of an if statement
will be executed if the Boolean expression of the if clause is true.
Otherwise it will be skipped and the operation will be continued with
the next statement.
4.5.3.2. Conditional statement.
According to the syntax two different
forms of conditional statements are possible. These may be illustrated
as follows:
if B1 then S1 else if B2 then S2 else S3; S4
if B1 then S1 else if B2 then S2 else if B3 then S3; S4Here B1 to B3 are Boolean expressions, while S1 to S3 are unconditional statements. S4 is the statement following the complete conditional statement.
The execution of a conditional statement may be described as follows: The Boolean expression of the if clause are evaluated one after the other in sequence from left to right until one yielding the value S("true") is found. Then the unconditional statement following this Boolean is executed. Unless this statement defines its successor explicitly the next statement to be executed will be S4, i.e. the statement following the complete complete conditional statement. Thus the effect of the delimiter S("else") may be described by saying that it defines the successor of the statement it follows to be the statement following the complete conditional statement.
The construction
else unconditional_statementis equivalent to
else if true then unconditional_statement
If none of the Boolean expressions of the if clauses is true, the effect of the whole conditional statement will be equivalent to that of a dummy statement.
. . . . . . . . . ( end of section 4.5.3. Semantics of if.) <<Contents | End>>
4.5.4. Go to into a conditional statement.
The effect of a go to
statement leading into a conditional statement follows directly from the
above explanation of the effect of S("else").
. . . . . . . . . ( end of section 4.5) <<Contents | End>>
4.6. For statements
for q:=1 step s until n do A[q]:=B[q]
for k:=1,V1*2 while V1<N do
for j:=I+G,L,1 step 1 until N, C+D do A[k,j]:=B[k,j]
4.6.3. Semantics.
A for clause causes the statement S which it precedes
to be repeatedly executed zero or more times. In addition it performs a
sequence of assignments to its controlled variable. The process may be
visualized by means of the following picture:
[Omitted picture]
In this picture the word initialize means: perform the first assignment
of the for clause. Advance means: perform the next assignment of the
for clause. Test determines if the last assignment has been done. If
so, the execution continues with the successor of the for statement. If
not, the statement following the for clause is executed.
4.6.4. The for list elements.
4.6.4.1. Arithmetic expression.
This element gives rise to one value,
namely the value of the given arithmetic expression as calculated
immediately before the corresponding execution of the statement S.
4.6.4.2. Step-until-element.
An element of the form A S("step") B S("until") C, where A, B, and C are arithmetic expressions, gives rise to an execution which may be described most concisely in terms of additional Algol statement as follows:
V := A
L1: if (V-C)*sign(B) > 0 then goto ``Element exhausted'';
Statement S;
V := V+B;
goto L1;where V is the controlled variable of the for clause and `Element exhausted' points to the evaluation according to the next element in the for list, or if the step-until-element is the last of the list, to the next statement in the program.
4.6.4.3. While-element.
The execution governed by a for list element
of the form E S("while") F, where E is an arithmetic and F a Boolean
expression, is most concisely described in terms of additional Algol
statements as follows:
L3: V := E
if ~ F then goto ``Element exhausted'';
Statement S;
goto L3;
where the notation is the same as in 4.6.4.2 above.
4.6.5. The value of the controlled variable upon exit.
Upon exit out
of the statement S (supposed to be compound) through a go to statement
the value of the controlled variable will be the same as it was
immediately preceding the execution of the go to statement.
If the exit is due to exhaustion of the for list, on the other hand, the value of the controlled variable is undefined after the exit.
4.6.6. Go to leading into a for statement.
The effect of a go to
statement, outside a for statement, which refers to a label within the
for statement, is undefined.
. . . . . . . . . ( end of section 4.6.4. The for list elements.) <<Contents | End>>
. . . . . . . . . ( end of section 4.6) <<Contents | End>>
4.7. Procedure statements
Spur (A) Order: (7) Result to: (V)
Transpose (W, v+1)
Absmax (A, N, M, Yy, I, K)
Innerproduct (A [t,P,u], B [P], 10, P, Y)These examples correspond to examples given in section 5.4.2. [ #5.4.2. Example Procedures ]
. . . . . . . . . ( end of section 4.7.3. Semantics.) <<Contents | End>>
4.7.4. Actual-formal correspondence.
The correspondence between the
actual parameters of the procedure statement and the formal parameters
of the procedure heading is established as follows: The actual parameter
list of the procedure statement must have the same number of entries as
the formal parameter list of the procedure declaration heading. The
correspondence is obtained by taking the entries of these two lists in
the same order.
4.7.5. Restrictions.
This imposes the restriction on any procedure statement that the kind and type of each actual parameter to be compatible with the kind and type of the corresponding formal parameter. Some important particular cases of this general rule are the following:
4.7.5.1.
If a string is supplied as an actual parameter in a procedure
statement or function designator, whose defining procedure body is an
Algol 60 statement (as opposed to non-Algol code, cf. section 4.7.8),
then this string can only be used within the procedure body as an actual
parameter in further procedure calls. Ultimately it can only be used by
a procedure body expressed in non-Algol code.
4.7.5.2.
A formal parameter which occurs as a left part variable in an
assignment statement within the procedure body and which is not called
by value can only correspond to an actual parameter which is a variable (special case of expression).
4.7.5.3.
A formal parameter which is used within the procedure body as
an array identifier can only correspond to an actual parameter which is
an array identifier of an array of the same dimensions. In addition if
the formal parameter is called by value the local array created during
the call will have the same subscript bounds as the actual array.
4.7.5.4.
A formal parameter which is called by value cannot in general
correspond to a switch identifier or a procedure identifier or a string,
because these latter do not possess values (the exception is the
procedure identifier of a procedure declaration which has an empty
formal parameter part (cf. section 5.4.1) and which defines the value
of a function designator (cf. section 5.4.4). This procedure
identifier is in itself a complete expression).
4.7.5.5.
Any formal parameter may have restrictions on the type of the
corresponding actual parameter associated with it (these restrictions
may, or may not, be given through specifications in the procedure
heading). In the procedure statement such restrictions must evidently
be observed.
. . . . . . . . . ( end of section 4.7.5. Restrictions.) <<Contents | End>>
4.7.7. Parameter delimiters.
All parameter delimiters are understood
to be equivalent. No correspondence between the parameter delimiters
used in a procedure statement and those used in the procedure heading is
expected beyond their number is the same. Thus the information conveyed
by using the elaborate ones is entirely optional.
4.7.8. Procedure body expressed in code.
The restrictions imposed on a
procedure statement calling a procedure having its body expressed in
non-Algol code evidently can only be derived from the characteristics of
the code used and the intent of the user and thus fall outside the scope
of the reference language.
Declarations serve to define certain properties of the quantities used in the program, and to associate them with identifiers. A declaration of an identifier is valid for one block. Outside this block the particular identifier may be used for other purposes (cf. section 4.1.3).
Dynamically this implies the following: at the time of an entry into a block (through the S("begin") since the labels inside are local and therefore inaccessible from outside) all identifiers declared for the block assume the significance implied by the nature of the declarations given. If these identifiers had already been defined by other declarations outside they are for the time being given a new significance. Identifiers which are not declared for the block, on the other hand, retain their old meaning.
At the time of an exit from an block (through S("end"), or by a go to statement) all identifiers which are declared for the block lose their local significance.
A declaration my be marked with the additional declarator S("own").
This has the following effect: upon a reentry into the block, the values
of own quantities will be unchanged from their values at the last exit,
while the values of declared variables which are not marked as own are
undefined. Apart from labels and formal parameters of procedure
declarations and with the possible exception of those for standard
functions (cf. sections 3.2.4 and 3.2.5) all identifiers of a program
must be declared. No identifier may be declared more than once in any
one block head.
Syntax.
integer p, q, s
own Boolean Acryl, n
In arithmetic expressions any position which can be occupied by a real declared variable may be occupied by an integer declared variable.
For the semantics of S("own"), see the fourth paragraph of section 5 above.
. . . . . . . . . ( end of section 5.1) <<Contents | End>>
5.2. Array declarations
array a, b, c [7:n, 2:m], s [-2:10]
own integer array A [ if c<0 then 2 else 1:20]
real array q [-7:-1]
. . . . . . . . . ( end of section 5.2.3. Semantics of array declarations.) <<Contents | End>>
5.2.4. Lower upper bound expressions.
. . . . . . . . . ( end of section 5.2.4) <<Contents | End>>
5.2.5. The identity of subscripted variables.
The identity of a
subscripted variable is not related to the subscript bounds given in the
array declaration. However, even if an array is declared S("own") the
values of the corresponding subscripted variables will, at any time, be
defined only for those of these variables which have subscripts within
the most recently calculated subscript bounds.
. . . . . . . . . ( end of section 5.2) <<Contents | End>>
5.3. Switch declarations
switch S:=S1,S2,Q[m], if v>-5 then S3 else S4
switch Q:=p1,w
5.3.3. Semantics.
A switch declaration defines the set of values of
the corresponding switch designators. These values are given one by one
as the values of the designational expressions entered in the switch
list. With each of these designational expressions there is associated
a positive integer, 1, 2, ..., obtained by counting the items in the
list from left to right. The value of the switch designator
corresponding to a given value of the subscript expression (cf. section
3.5. Designational expressions) is the value of the designational
expression in the switch list having this given value as its associated
integer.
5.3.4. Evaluation of expressions in the switch list.
An expression in
the switch list will be evaluated every time the item of the list in
which the expression occurs is referred to, using the current values of
all variables involved.
5.3.5. Influence of scopes.
If a switch designator occurs outside the
scope of a quantity entering into a designational expression in the
switch list, and an evaluation of this switch designator selects this
designational expression, then the conflicts between the identifiers for
the quantities in this expression and the identifiers whose declarations
are valid at the place of the switch designator will be avoided through
suitable systematic changes of the latter identifiers.
. . . . . . . . . ( end of section 5.3) <<Contents | End>>
5.4. Procedure declarations
procedure Spur (a) Order: (n); value n;
array a; integer n; real s;
begin integer k;
s:=0;
for k:=1 step 1 until n do s:=s+a[k,k]
end
procedure Transpose (a) Order: (n); value n;
array a; integer n;
begin real w; integer i, k;
for i := 1 step 1 until n do
for k := 1+i step 1 until n do
begin w:=a[i,k];
a[i,k]:=a[k,i];
a[k,i]:=w
end
end Transpose
integer procedure Step (u); real u;
Step:=if 0<=u/\u<=1 then 1 else 0
procedure Absmax (a) Size: (n, m) Result: (y) Subscripts: (i, k);
comment The absolute greatest element of the matrix a, of size n by m
is transferred to y, and the subscripts of this element to i and k;
array a; integer n, m, i, k; real y;
begin integer p, q;
y := 0;
for p:=1 step 1 until n do for q:=1 step 1 until m do
if abs(a[p,q]])>y then begin y:=abs(a[p,q]);
i:=p; k:=q end end Absmax
procedure Innerproduct (a, b) Order: (k, p) Result: (y); value k;
integer k, p; real y, a, b;
s:=0;
for p:=1 step 1 until k do s:=s+a*b;
y:=s
end Innerproduct
5.4.4. Values of function designators. For a procedure declaration to define the value of a function designator there must, within the procedure declaration body, occur one or more explicit assignment statements with the procedure identifier in a left part; at least one of these must be executed, and the type associated with the procedure identifier must be declared through the appearance of a type declarator as the very first symbol of the procedure declaration. The last value so assigned is used to continue the evaluation of the expression in which the function designator occurs. Any occurrence of the procedure identifier within the body of the procedure other than in a left part in an assignment statement denotes activation of the procedure.
5.4.5. Specifications. In the heading a specification part, giving information about the kinds and types of the formal parameters by means of an obvious notation, may be included. In this part no formal parameter may occur more than once. Specification of formal parameters called by value (cf. section 4.7.3.1) must be supplied and specifications of formal parameters called by name (cf. section 4.7.3.2) may be omitted.
5.4.6. Code as procedure body.
It is understood that the procedure
body may be expressed in non-Algol language. Since it is intended that
the use of this feature should be entirely a question of hardware
representation, no further rules concerning this code language can be
given within the reference language.
. . . . . . . . . ( end of section 5. Declarations) <<Contents | End>>
Examples
. . . . . . . . . ( end of section Examples) <<Contents | End>>
. . . . . . . . . ( end of section Description) <<Contents | End>>
. . . . . . . . . ( end of section Syntax) <<Contents | End>>
From A.R.Diller@computer-science.birmingham.ac.uk Thu Mar 2 15:20 PST 1995
Date: Thu, 2 Mar 95 17:05:14 GMT
From: A.R.Diller@computer-science.birmingham.ac.uk
Message-Id: <1711.9503021705@fat-controller.cs.bham.ac.uk>
To: dick@blaze.csci.csusb.edu
Thanks for the information concerning the online Algol60 report. A colleague of mine is a Wittgenstein expert and concerning the quote and he informs me that:
The first bit
Was sich ueberhaupt sagen laesst, laesst sich
klar sagen;
means "what can be said at all can be said clearly" and is the 2nd sentence in Tractatus 4.116.
The second bit:
und wovon man nicht reden
kann, darueber muss man schweigen.
means "whereof we cannot speak, thereover must we pass in silence", and is the famous Tractatus 7.
The two bits may be together in some other (perhaps) preparatory piece of writing.
I hope that helps,
Antoni Diller
. . . . . . . . . ( end of section End Notes) <<Contents | End>>