Info file: RRA60.info, *Text*
produced by latexinfoformatbuffer
from file: RRA60.texinfo
File: RRA60.info Node: Top, Prev: (dir), Up: (dir), Next: Introduction
Revised Report on the Algorithmic Language Algol 60
=====================================================
By
J.W. Backus, F.L. Bauer, J.Green, C. Katz, J. McCarthy
P. Naur, A.J. Perlis, H. Rutishauser, K. Samelson, B. Vauquois
J.H. Wegstein, A. van Wijngaarden, M. Woodger
Edited by
Peter Naur
Dedicated to the memory of William Turanski
* Menu:
* Introduction:: Introduction
* Description:: Description of the reference language
* Editors note:: Note by the Editor
Summary

The report gives a complete defining description of the international
algorithmic language Algol 60. This is a languge suitable for
expressing a large class of numerical processes in a form sufficiently
concise for direct automatic translation into the language of
programmed automatic computers.
The introduction contains an account of the preparatory work leading
up to the final conference, where the language was defined. In
addition the notions reference language, publication language, and
hardware representations are explained.
In the first chapter a survey of the basic constituents and features
of the language is given, and the formal notation, by which the
syntactic structure is defined, is explained.
The second chapter lists all the basic symbols, and the syntactic
units known as identifiers, numbers, and strings are defined. Further
some important notions such as quantity and value are defined.
The third chapter explains the rules for forming expressions and the
meaning of these expressions. Three different types of expressions
exist: arithmetic, Boolean (logical), and designational.
The fourth chapter describes the operational units of the language,
known as statements. The basic statements are: assignment statements
(evaluation of a formula), go to statements (explicit break of the
sequence of execution of statements), dummy statements, and procedure
statements (call for execution of a closed process, defined by a
procedure declaration). The formation of more complex structures,
having statement character, is explained. These include: conditional
statements, for statements, compound statements, and blocks.
In the fifth chapter the units known as declarations, serving for
defining permanent properties of the units entering into a process
described in the language, are defined.
The report ends with two detailed examples of the use of the language
and an alphabetic index of definitions.
File: RRA60.info Node: Introduction, Prev: Top, Up: Top, Next: Description
Introduction
==============
Background

After the publication (1)(2) of a preliminary report on the
algorithmic language Algol, as prepares at the conference in Zuerich
in 1958, much interest in the Algol language developed.
(1) Preliminary report  International Algebraic Language, Comm.
Assoc. Comp. Mach. 1, No. 12 (1958), 8.
(2) Report on the Algorithmic Language Algol by the ACM Committee
on Programming Languages and the GAMM Committee on Programming,
edited by A. J. Perlis and K. Samuelson, Numerische Mathematik
Bd. 1, S. 4160 (1959).
As a result of an informal meeting held at Mainz in November 1958, about
forty interested persons from several European countries held an Algol
implementation conference in Copenhagen in February 1959. A "hardware
group" was formed for working cooperatively right down to the level of
the paper tape code. This conference also led to the publication by
Regnecentralen, Copenhagen, of an `Algol Bulletin', edited by Peter
Naur, which seved as a forum for further discussion. During the June
1959 ICIP Conference in Paris several meetings, both formal and informal
ones, were held. These meetings revealed some misunderstandings as to
the intent of the group which was primarily responsible for the
formulation of the language, but at the same time made it clear that
there exists a wide appreciation of the effort involved. As a result of
the discussions it was decided to hold an international meeting in
January 1959 for improving the Algol language and preparing a final
report. At a European Algol Conference in Paris in November 1959 which
was attended by about fifty people, seven European representatives were
selected at attend the January 1960 Conference, and they represent the
following organisations: Association Francaise de Calcul, British
Computer Society, Gesellschaft fuer Angewandte Mathematik und
Mechanik, and the Nederlands Rekenmachine Genootschap. The seven
representatives held a final preparatory meeting at Mainz in December
1959.
Meanwhile, in the United States, anyone who wished to suggest changes or
corrections to Algol was requested to send his comments to the
`Communications of the ACM', where they were published. These comments
then became the basis of consideration for changes in the Algol
language. Both the SHARE and USE organisations established Algol
working groups, and both organisations were represented on the ACM
Committee on Programming Languages. The ACM Committee met in Washington
in November 1959 and considered all comments on Algol that had been sent
to the ACM `Communications'. Also, seven representatives were selected
to attend the January 1960 international conference. The seven
representatives held a final preparatory meeting in Boston in December
1959.
January 1960 Conference

The thirteen representatives (1), from Denmark, England, France,
Germany, Holland, Swiutzerland, and the United States, conferred in
Paris from January 11 to 16, 1960.
(1) William Turanski of the American group was killed by an automobile
just prior to the January 1960 Conference.
Prior to this meeting a completely new draft report was worked out from
the preliminary report and the recommendations of the preparatory
meetings by Peter Naur and the Conference adopted this new form as the
basis for its report. The Conference then proceeded to work for
agreement on each item of the report. The present report represents the
union of the Committee's concepts and the intersection of its agreements.
April 1962 Conference [Edited by M. Woodger]
==============================================
A meeting of some of the authors of Algol 60 was held on 2nd  3rd April
in Rome, Italy, through the facilities and courtesy of the International
Computation Centre. The following were present:
Authors Advisers Observer
F. L. Bauer M. Paul W. L. van der Poel
J. Green R. Franciotti (Chairman, IFIP TC 2.1
C. Katz P. Z. Ingerman Working Group Algol)
R. Kogon (representing
J.W. Backus)
P. Naur
K. Samuelson G. Seegemueller
J. H. Wegstein R.E. Utman
A. van Wijngaarden
M. Woodger P. Landin
The purpose of the meeting was to correct known errors in, attempt to
eliminate apparent ambiguities in, and otherwise clarify the Algol 60
Report. Extensions to the language were not considered at the meeting.
Various proposals for correction and clarification that were submitted
by interested parties in response to the Questionnaire in Algol Bulletin
No. 14 were used as a guide.
This report constitutes a supplement to the Algol 60 Report which should
resolve a number of difficulties therein. Not all of the questions
raised concerning the original report could be resolved. Rather than
risk of hastily drawn conclusions on a number of subtle points, which
might create new ambiguities, the committee decided to report only those
points which thay unanimously felt could be stated in clear and
unambiguous fashion.
Questions concerned with the following areas left for further consideration by
Working Group 2.1 of IFIP, in the expectation that current
work on advanced programming languages will lead to
better resolution:
1. Side effects of functions.
2. The call by name concept.
3. 'own': static or dynamic.
4. For statement: static or dynamic.
5. Conflict between specification and declaration.
The authors of the Algol 60 Report present at the Rome Conference,
being aware of the formation of a Working Group on Algol by IFIP,
accepted that any collective responsibility which they might have with respect to the development, specification, and refinement of the Algol language
will from now on be transferred to that body.
This report has been reviewed by IFIP TC 2 on Programming Languages in August 1962 and
has been approved by the Council of the International Federation for
Information Processing.
As with the preliminary Algol report, three different levels of language
are recognized, namely a Reference Language, a Publication Language, and
several Hardware Representations.
Reference Language
1. It is the working language of the committee.
2. It is the defining language.
3. The characters are determined by ease of mutual understanding and
not by any computer limitations, coders notation, or pure
mathematical notation.
4. It is the basic reference and guide for compiler builders.
5. It is the guide for all hardware representaions.
6. It is the guide for transliterating from publication language to
any locally appropriate hardware representations.
7. The main publications of the Algol language itself will use the
reference representation.
Publication Language
1. The publication language admits variations of the reference
language according to usage of printing and handwriting (e.g.
subscripts, spaces, exponents, Greek letters).
2. It is used for stating and communicating process.
3. The caracters used may be different in different countries, but
univocal correspondence with reference representaion must be
secured.
Hardware Representations
1. Each of these is a condensation of the reference language enforced
by the limited number of characters on the standard input
equipment.
2. Each one of these uses the character set of a particular computer
and is the language accepted by a translator for that computer.
3. 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.
Parantheses () Any form of parantheses, brackets,
braces.
Basis of ten '10' Raising of the ten and of the following
integral number, inserting of the
intended multiplication sign.
File: RRA60.info Node: Description, Prev: Introduction, Up: Top, Next: Structure
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
* Menu:
* Structure:: 1. Structure of the language
* Basic:: 2. Basic symbols, identifiers, numbers, and strings
* Expressions:: 3. Expressions
* Statements:: 4. Statements
* Declarations:: 5. Declarations
* Examples:: Examples of procedure declarations
* Index:: Alphabetic index of concepts and syntactic units
* Note:: Note
File: RRA60.info Node: Structure, Prev: Description, Up: Description, Next: Basic
1. Structure of the language

As stated in the introdution, the algorithmic language has three
different kinds of representations  reference, hardware, and
publication  and the development described in the squel 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, selfcontained units of the
language  explicit formulae  called assignment statements.
To show the flow of computational processes, certain nonarithmetic
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 'begin'
and '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
'begin' and '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 (1).
(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.
1.1 Formalism for syntactic description.
..........................................
The syntax will be described with the aid of metalinguistic formulae
(1).
(1) Cf. J. W. Backus, The syntax and semantics of the proposed
international algebraic language of the Zuerich ACMGRAMM
conference. ICIP Paris, June 1959.
Their interpretation is best explained by an example:
::= (  [  ( 
Sequences of characters enclosed in the bracket <> represent
metalinguistic variables whose values are sequences of symbols. The
marks ::= and  (the latter with the meaning of or) are
metalinguistic connectives. Any mark in a formula, which is not a
variable or a connective, denotes itself (or the class of marks which
are similar to it). Juxta position of marks and/or variables in a
formula signifies juxtaposition of the sequences denoted. Thus the
formula above gives a recursive rule for the formation of values of the
variable . It indicates that may have the value (
or [ or that given some legitimate value of , another may be
formed by following it with the character ( or by following it with some
value of the variable . If the values of are the
decimal digits, some values of are:
[(((1(37(
(12345(
(((
[86
In order to facilitate the study, the symbols used for distinguishing
the metalinguistic variables (i.e. the sequence of characters appearing
within the brackets <> as AB in the above example) have been choosen to
be words describing approximately the nature of the corresponding
variable. Where words which have appeared in this manner are used
elsewhere in the text they will refer to the corresponding syntactic
definition. In addition some formulae have been given in more than one
place.
Definition:
::=
(i.e. the null string of symbols).
File: RRA60.info Node: Basic, Prev: Structure, Up: Description, Next: Expressions
2. Basic symbols, identifiers, numbers, and strings.

Basic concepts

The reference language is built up from the following basic symbols:
::=   
2.1. Letters
..............
::= a  b  c  d  e  f  g  h  i  j  k  l  m  n  o 
p  q  r  s  t  u  v  w  x  y  z  A  B  C  D  E 
F  G  H  I  J  K  L  M  N  O  P  Q  R  S  T  U 
V  W  X  Y  Z
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 (1) (cf. sections 2.4. Identifiers, 2.6.
Strings).
(1) It should be particularly noted that throughout the reference
language underlining [here this looks like 'underlined' 
(schoenfr)] 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.
::= 0  1  2  3  4  5  6  7  8  9
Digits are used for forming numbers, identifiers, and strings.
2.2.2 Logical values.
::= 'true'  'false'
The logical values have a fixed obvious meaning.
2.3. Delimiters
.................
::=    
::=    ::= +    *  /  'div'  ^
::= <  <=  =  >=  >  !=
::= 'equiv'  'impl'  'or'  'and'  'not'
::= 'goto'  'if'  'then'  'else'  'for'  'do'
(2)
::= ,  .  '10'  :  ;  :=  _  'step'  'until' 
'while'  'comment'
::= (  )  [  ]  `  '  'begin'  'end'
::= 'own'  'Boolean'  'integer'  'real'  'array' 
'switch'  'procedure'
::= 'string'  'label'  'value'
(2) 'do' is used in for statements. It has no relation to the do of the
preliminary report, which is not included in Algol60.
Delimiters have a fixed meaning which for the most part is obvious or
else will be given at the appropriate place in the sequel.
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.
For the purpose of including text among the symbols of a program the
following "comment" conventions hold:
The sequence of basic symbols: is equivalent to
; 'comment' ; ;
'begin' 'comment' ; 'begin'
'end' 'end'
By equivalence is here meant that any of the three structures shown in
the left hand column may be replaced, in any occurence outside of
strings, by the symbol shown in the same line in the right hand
column 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.
2.4. Identifiers
..................
2.4.1. Syntax.
::= LETTER>  
2.4.2. Examples.
q
Soup
V17a
a34kTMNs
MARILYN
2.4.3. Semantics. Identifiers have no inherent meaning, but serve for
the identification of simple variables, arrays, labels, switches, and
procedures. They may be choosen freely (cf. however section 3.2.4.
Standard functions).
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).
2.5. Numbers
..............
2.5.1 Syntax.
::=  ::=  + 
 ::= . ::= '10' ::=  
::=  
::=  + 

2.5.2. Examples.
0 200.084 .083'10'02
177 + 07.43'10'8 '10'7
.5384 9.34'10'+10 '10'4
+0.7300 2'10'4 +'10'+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 'integer'. All other
numbers are of type 'real' (cf. section 5.1 Type declarations).
2.6. Strings
..............
2.6.1. Syntax.
::= 
::= `'  ::= `'
2.6.2. Examples.
`5k,,`[[[`'and'=/:'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).
2.7. Quantities, kinds and scopes
...................................
The following kinds of quantities are distinguished: simple variables,
arrays, labels, switches, and procedures.
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.
2.8. Values and types
.......................
A value is an ordered set of numbers (special case: a single number), an
ordered set of logical values (special case: a single logical value), or
a label.
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 thair 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" ('integer', 'real', 'Boolean')
basically denote properties of values. The types associated with
syntactic units refer to the values of these units.
File: RRA60.info Node: Expressions, Prev: Basic, Up: Description, Next: Statements
3. Expressions

In the language the primary constituents of the programs describing
algorithmic processes are arithmetic, Boolean, and designational
expressions. Constituents of the expressions, except for certain
delimiters, are logical values, numbers, variables, fuction designators,
and elementary arithmetic, relational, logical, and sequenctial
operators. Since the syntactic definition of both variables and
function designators contains expressions, the definition of
expressions, and their constituents, is necessarily recursive.
::= 

3.1. Variables
................
3.1.1. Syntax
::= ::= ::= ::= 
, ::= ::=
[ ]
::= 
3.1.2. Examples
epsilon
detA
a17
Q[7,2]
x[sin(n*pi/2),Q[3,n,4]]
3.1.3. Semantics. A variable is a designation given to a single value.
This value may be used in expressions for forming other values and may
be changed at will by means of assignment statements (section 4.2). The
type of the value of a particular variable is defined in the declaration
for the variable itself (cf. section 5.1. Type declarations) or for
the corresponding array identifier (cf. section 5.2. Array declarations),
3.1.4. Subscripts. 3.1.4.1. Subscripted variables designate values
which are components of multidimensional arrays (cf. section 5.2.
Array declarations). Each arithmetic expression of the subscript list
occupies one subscript position of the subscripted variable and is
called a subscript. The complete list of subscripts is enclosed in the
subscript brackets [ ]. The array component referred to by a
subscripted variable is specified by the actual numerical value of its
subscripts (cf. section 3.3. Arithmetic expressions).
3.1.4.2. Each subscript position acts like a variable of type
'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).
3.2. Function designators
...........................
3.2.1. Syntax
::= ::=  
 
::=  ::= ,  ) : (
::= 
::= 
( )
::=
3.2.2. Examples
sin(ab)
J(v+s,n)
R
S(s5) Temperature: (T) Pressure: (P)
Compile (`:=') Stack: (Q)
3.2.3. Sematics. 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:
abs (E)
for the modulus (absolute value) of the value of the
expression E
sign (E)
for the sign of the value of E (+1 for E>0, 0 for E=0,
1 for E<0)
sqrt (E)
for the square root of the value of E
sin (E)
for the sine of the value of E
cos (E)
for the cosine of the value of E
arctan (E)
for the principal value of the arctangent of the value
of E
ln (E)
for the natural logarithm of the value of E
exp (E)
for the exponential function of the value
of E (e ^ E)
These functions are all understood to operate indifferently on arguments
both of type 'real' and 'integer'. They will all yield values
of type 'real', except for sign (E) which will have values of type
'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.
3.3. Arithmetic expressions
.............................
3.3.1. Syntax
::= +  
::= *  /  'div'
::=  
 ( )
::=  
^ ::=  ::= 

::= 'if' 'then'
::= 
'else'
3.3.2. Examples.
Primaries:
7.394'10'8
sum
w[i+2,8]
cos(y+z*3)
(a3/y+vu^8)
Factors:
omega
sum^cos(y+z*3)
7.394'10'8^w[i+2,8]^(a3/y+vu^8)
Terms:
U
omega*sum^cos(y+z*3)/7.394'10'8^w[i+2,8]^(a3/y+vu^8)
Simple arithmetic expressions:
UYu+omega*sum^cos(y+z*3)/7.394'10'8^w[i+2,8]^
(a3/y+vu^8)
Arithmetic expressions:
w*uQ(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'10'12*a[N*(N1)/2,0]
(A*arctan(y)+Z)^(7+Q)
'if' q 'then' n1 'else' n
'if' a<0 'then' A/B 'else' 'if' b=0 'then' B/A 'else' z
3.3.3. Semantics. An arithmetic expression is a rule for computing a
numerical value. In case of simple arithmetic expressions this value
is obtained by executing the indicated arithmetic operations on the
actual numerical values of the primaries of the expression, as explained
in detail in section 3.3.4 below. The actual numerical value for a
primary is obvious in the case of numbers. For variables it is the
current value (assigned last in the dynamic sense), and for function
designators it is the value arising from the computing rules defining
the procedure (cf. section 5.4.4. Values of function designators) when
applied to the current values of the procedure parameters given in the
expression. Finally, for arithmetic expressions enclosed in parentheses
the value must through a recursive analysis be expressed in terms of the
values of primaries of the other three kinds.
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 '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:
'else'
is equivalent to the construction:
'else' 'if' 'true' 'then'
3.3.4. Operators and types. Apart from the Boolean expressions of if
clauses, the constituents of simple arithmetic expressions must be of
types 'real' or 'integer' (cf. section 5.1. Type
declarations). The meaning of the basic operators and the types of the
expressions to which they lead are given by the following rules:
3.3.4.1. The operators +, , and * have the conventional meaning
(addition, subtraction, and multiplication). The type of the expression
will by 'integer' if both of the operands are of 'integer'
type, otherwise 'real'.
3.3.4.2. The operations / and 'div'
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/(pq)*v/s
means
((((a*(b^1))*7)*((pq)^1))*v)*(s^1)
The operator / is defined for all four combinations of types 'real' and
'integer' and will yield results of 'real' type in any case. The
operator 'div' is defined only for two operands of type 'integer' and
will yield a result of type 'integer', mathematically defined as
follows:
a 'div' b = sign(a/b) * entier(abs(a/b))
(cf. sections 3.2.4 and 3.2.5).
3.3.4.3. The operation ^ denotes exponentation, 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 'integer' type, r for a number of 'real' type,
and a for a number of ether 'integer' or '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 'real'.
if a=0: undefined.
a ^ r
if a>0: exp(r*ln(a)), of type 'real'.
if a=0, if r>0: 0.0, of type 'real'.
if r<=0: undefined.
if a<0: always undefined.
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: * / 'div'
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
opearations within an expression can always be arranged by appropriate
positioning of parenthesis.
3.3.6. Arithmetics of 'real' quantities. Numbers and variables of type
'real' must be interpreted in the sense of numerical analysis, i.e. as
entities defined inherently with only a finite accuracy. Similary, the
possibility of the occurance 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.
3.4. Boolean expressions
..........................
3.4.1. Syntax.
::= <  <=  =  >=  >  !=
::= ::=  
 
( )
::= 
'not' ::= 
'and' ::= 
'or' ::= 
'impl' ::= 
'equiv' ::=  'else'
3.4.2. Examples.
x=2
Y>V'or'z5'and'zd>q^2
p'and'q'or'x!=y
g'equiv''not'a'and'b'and''not'c'or'd'or'e'impl''not' f
'if' k<1 'then' s= > !=
third: 'not'
fourth: 'and'
fifth: 'or'
sixth: 'impl'
seventh: 'equiv'
3.4.6.2. The use of parentheses will be interpreted in the sense given
in section 3.3.5.2.
3.5. Designational expressions
................................
3.5.1. Syntax.