Trailing-Edge
-
PDP-10 Archives
-
decuslib20-03
-
decus/20-0078/doc/simlh1.man
There are no other files named simlh1.man in the archive.
DECSYSTEM-10 SIMULA Language Handbook, Part I
---------------------------------------------
By Graham Birtwistle, Lars Enderin, Mats Ohlin and Jacob Palme
Abstract
--------
The DECsystem-10 SIMULA Language Handbook contains the information
necessary for an applications programmer who intends to use SIMULA on
a DECsystem-10 computer.
Part I contains a description of the SIMULA programming language. It
is a guide to the language consisting of four chapters. The first
chapter introduces SIMULA by way of some fully discussed examples.
Chapter two gives the syntax and semantics of SIMULA. The third
chapter describes (with furhter examples) the standard system classes
and text handling facilities. The last chapter deals with separate
compilation of procedures and classes. Part II contains special
information for DECsystem-10. Part III describes the SIMULA Utility
Library (LIBSIM).
SIMULA is a general-purpose high-level programming language comparable
in power to PL/I or Algol 68. SIMULA is based on ALGOL 60 with the
addition of record-oriented dynamic memory allocation, reference
(pointer) structures, sets and queues, text- and character handling,
sequential and direct access input-output, quasi-parallel sequencing
(coroutines) and process (event) oriented simulation capabilities.
SIMULA is designed in a way which makes it easy to produce
perspiciuous, well-structured, readable and secure programs. SIMULA
is well adapted to structured programming methodology.
SIMULA will often considerably reduce the programming time compared to
conventional languages like FORTRAN, COBOL, or PL/I.
SIMULA on the DECsystem-10 contains two major additions to the SIMULA
language: A system for separately compiled program modules in SIMULA,
FORTRAN, or MACRO 10 and a powerful on-line debugging system, SIMDDT.
The DECsystem-10 SIMULA compiler requires 25 to 30K user area and
compiles at roughly half the speed of the DECsystem-10 ALGOL compiler.
The CPU time when running SIMULA programs is about the same as for
ALGOL, faster for input-output and text string handling, slower for
stack-oriented memory allocation.
Key word and phrases: Computer, Programming, Programming Language,
SIMULA, DECsystem-10, Digital Equipment, PL/I, Algol 60, Algol 68,
Fortran, Cobol, Dynamic Memory Allocation, List structure, Data
structure, Record, Set, Queue, Text, String, Character, Coroutine,
Process, Event, Simulation, Structured Programming, Separate
Compilation, Part-compilation, Debugging, On-line debugging.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 2
CHAPTER 1
Copyright (c) Swedish National Defense Research Institute and the
Norwegian Computing Center.
This handbook may not be sold, bought, copied or otherwise distributed
for usage primarily as a manual with another SIMULA system than the
DECsystem-10 SIMULA system.
The word "SIMULA" is a registered trademark of the Norwegian Computing
Center.
NTIS Number: PB-243 064.
DECsystem-10 SIMULA was produced and is presently maintained by the
Swedish National Defense Research Institute, Section 142, S-10450
Stockholm 80, Sweden. If you send your name and address to that
address, you will be put on the mailing list for a newsletter for
DECsystem-10 SIMULA users.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 3
CHAPTER 1
CONTENTS
--------
BIBLIOGRAHPHY
CHAPTER 1 BASIC SIMULA
-----------------------
COMPILE TIME AND RUN TIME
1.1 THE HIGHEST MARK
1.2 NUMBERING A CROSSWORD PUZZLE
1.3 GEOMETRIC APPLICATIONS
1.4 SIMULATION OF A QUEUEING SITUATION
CHAPTER 2 THE SYNTAX AND SEMANTICS OF SIMULA
---------------------------------------------
2.1 METHOD OF SYNTAX SPECIFICATION
2.2 BASIC SYMBOLS AND SYNTACTIC VARIABLES
2.2.1 LANGUAGE CHARACTER SET
2.2.2 BASIC SYMBOLS
2.2.3 DATA CHARACTER SET
2.2.4 THE USE OF BLANKS
2.2.5 COMMENT CONVENTIONS
2.2.6 CODING SIMULA PROGRAMS
2.3 IDENTIFIERS
2.4 TYPES AND CONSTANTS
2.4.1 TYPES
2.4.2 CONSTANTS
2.5 DECLARATIONS
2.5.1 TYPE DECLARATIONS
2.5.2 ARRAY DECLARATIONS
2.5.3 SWITCH DECLARATIONS
2.5.4 PROCEDURE DECLARATIONS
2.5.5 CLASS DECLARATIONS
2.5.6 EXTERNAL DECLARATIONS
2.5.7 HIDDEN PROTECTED SPECIFICATIONS
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 4
CHAPTER 1
2.6 EXPRESSIONS
2.6.1 VARIABLES
2.6.2 FUNCTION DESIGNATORS
2.6.3 ARITHMETIC EXPRESSIONS
2.6.4 BOOLEAN EXPRESSIONS
2.6.5 CHARACTER EXPRESSIONS
2.6.6 DESIGNATIONAL EXPRESSIONS
2.6.7 OBJECT EXPRESSIONS
2.6.8 TEXT EXPRESSIONS AND TEXT VALUES
2.7 BLOCKS AND STATEMENTS
2.7.1 BLOCKS AND COMPOUND STATEMENTS
2.7.2 STATEMENTS
CHAPTER 3 SYSTEM CLASSES AND TEXT HANDLING
-------------------------------------------
3.1 PROGRAM STRUCTURE
3.2 CLASS SIMSET
3.3 CLASS SIMULATION
3.4 TEXT
3.5 CLASS BASICIO
CHAPTER 4 SEPARATE COMPILATION
-------------------------------
4.1 WHY SEPARATE COMPILATION?
4.2 GOOD AND BAD SEPARATE COMPILATION
4.3 WHAT SIMULA CONCEPTS CAN BE SEPARATELY COMPILED?
4.4 HOW IS SEPARATE COMPILATION SPECIFIED?
4.5 EXAMPLES OF PARTITIONING OF SIMULA PROGRAMS
APPENDIX A: ISO-7 (ASCII) CHARACTERS AS USED IN SIMULA
APPENDIX B: SYSTEM PROCEDURES
APPENDIX C: SKELETONS OF THE SYSTEM CLASSES AND SYSTEM PROCEDURES
INDEX
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 5
CHAPTER 1
BIBLIOGRAHPHY
-------------
(Defining document of ALGOL part of the SIMULA Language) Revised
Report on the Algorithmic Language ALGOL 60. Comm. ACM, 1963,
Vol. 6, No. 1, pp. 1-17.
(Defining document of SIMULA part of the SIMULA Language) SIMULA 67
Common Base Language. Publ. no S-22. Norwegian Computing Center,
Forskningsveien 1b, Oslo, Norway.
(Beginners textbook on SIMULA) SIMULA BEGIN. Studentlitteratur, Fack,
S-221 01 Lund 1, Sweden, or Mason and Lipscomb, Petrocelli Book
Division, 384 Fifth Avenue, New York, N Y 10018, U S A.
(Short introduction) A Primer on the CLASS and Pointer Concepts in
SIMULA. Report C 10043, Rapportcentralen, FOA 1, S-104 50 Stockholm
80, Sweden.
(Regular newsletter for SIMULA users) SIMULA newsletter. Norwegian
Computing Center, Forskningsveien 1b, Oslo, Norway.
(Newsletter for DECsystem-10 SIMULA users) DECsystem-10 SIMULA
Gazette. Section 142, Swedish National Defense Research Institute,
S-104 50 Stockholm 80, SWEDEN.
DEC-system 10 SIMULA Reference Card. Report C 10039,
Rapportcentralen, FOA 1, S-104 50 Stockholm 80, Sweden.
DEC-system 10 SIMULA Language Handbook:
Part I: The programming language SIMULA. Report no. C8398.
Part II: DECsystem-10 Dependent information, debugging. Report
no. C8399.
Part III: Utility Library. Report no. C10045.
Rapportcentralen, FOA 1, S-104 50 Stockholm 80, SWEDEN.
The DECsystem-10 SIMULA Handbooks and the primer on the CLASS and
Pointer Concepts will also be available as RUNOFF files on the SIMULA
distribution tape.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 6
CHAPTER 1
CHAPTER 1 BASIC SIMULA
-----------------------
The main purpose of this chapter is to introduce the concepts of the
SIMULA programming language. This is done through examples of
increasing scope.
The framing of a problem for computer solution takes place in two
phases. The first design phase consists of analysing the problem,
decomposing it into its components, classifying these components and
planning the flow of the computations. The second phase is coding,
that is expressing the plan of phase one in a programming language.
With many programming languages this will amount to a complete
rewriting, as the natural human modes of decomposition and
classification are not available within the language. This is not the
case with SIMULA, where concepts for a given problem or problem area
can be formulated directly in the language itself.
Thus SIMULA is more than just a notation for describing computing
processes - it also provides a framework for concept creation and is a
tool of thought in problem analysis.
The main features of SIMULA are presented in examples.
When developing the SIMULA program we will use capital letters for
items which are valid SIMULA, and lower case letters otherwise.
Thus
IF the carwash is idle THEN ACTIVATE the carwash
has two parts
the carwash is idle
the carwash
which have yet to be put into SIMULA.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 7
CHAPTER 1
COMPILE TIME AND RUN TIME
-------------------------
When a program is presented to a computer it is processed in two
distinct phases. In the first phase, the program written in SIMULA
(the source program) is translated into its equivalent in another
language already "known" by the computer. During this translation
stage, known as compile time, the source program is checked for
syntactic and semantic errors (illegal constructions, undeclared
variables, etc.) and, if any are found, the execution phase is
omitted. SIMULA has been designed to trap as many errors as possible
at compile time.
After successful compilation, the source program is no longer needed
and the computer operates on its translated form called the object
program. Since the two programs are equivalent, there is no need for
us to think of program execution in terms of the object program - we
can retain a mental picture of its execution in terms of the SIMULA
source program. The object program is executed supported by
prewritten routines called the run time system (RTS). This step is
called run time. At run time, the program data is read in when needed
and results printed out when requested in the program. Any errors
occurring at run time are called run time errors.
1.1 THE HIGHEST MARK
----------------
A class of students sits an examination and marks are awarded in the
range 0-100 as whole numbers (INTEGERS). A list of these marks is
presented to the computer. Write a program to find the highest mark.
A simple plan for the problem is this. Trace down the list of numbers
and process them one by one - at each stage comparing the present
value with the highest value met so far. (It is convenient to carry
along the highest value so far met to avoid repeated back-checking).
If the present value is the higher, then it replaces the old
highest-value-met, otherwise it has no significance. As the only
information we need retain is now noted, the present list value can be
discarded. Thus it is not necessary to retain the whole list of
numbers in the computer. The process is repeated taking the remaining
list members in turn until the list is exhausted when the last
highest-value-met is the number we require.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 8
CHAPTER 1.1
To follow this scheme we need note and compare the values of two
variables (called "variables" because their values vary during the
calculations). These we call "PRESENT" and "HIGHEST", the presently
considered list value and the highest value met so far, respectively.
A partial description of these actions could be:
step 1: let "PRESENT" be the new input value
step 2: if "PRESENT" is greater than "HIGHEST" then copy
the former's value into "HIGHEST".
The most concise and textually clear way of writing these actions is
to write them in a programming language - in this case SIMULA.
line no.
--------
READ: PRESENT := ININT; 1
IF PRESENT > HIGHEST THEN HIGHEST := PRESENT; 2
GOTO READ; 3
This piece of program contains three basic statements of different
types:
assignment-statement (line 1)
--------------------
variable := expression
where the value of the expression on the right is computed and
assigned to the variable on the left, i.e., the variable takes on the
value of the expression.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 9
CHAPTER 1.1
conditional-statement (line 2)
---------------------
IF condition THEN statement
where the statement is executed only if the condition is TRUE.
Another form of conditional statement is
IF condition THEN statement 1
ELSE statement 2
which is evaluated as:
1) evaluate the condition
2) if it is TRUE execute statement 1 and skip statement 2, if it
is FALSE then skip statement 1 and execute statement 2.
e.g.:
IF X < 0 THEN Y := -X ELSE Y := X
will assign the magnitude of X to Y.
GOTO-statement (line 3)
--------------
GOTO READ
which alters the sequence of execution of the statements from the
textual sequence to the one labelled "READ" (in this case).
Assignments are computational statements where data values are
altered. GOTO and IF-THEN-ELSE constructions are control statements
which respectively alter the program flow, and cause statements to be
skipped if the given condition does not hold.
The common operation of reading in the next INTEGER (whole number)
value is achieved by writing "ININT" whose value is that next whole
number in the input stream. "ININT" is thus a value which can be
assigned to a variable.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 10
CHAPTER 1.1
To separate out one statement from another in a program semicolons
(';') are used. Remember that statements do not themselves contain
semicolons. The other punctuation mark used here is the colon (':')
which separates out a label from the statement it identifies. Any
statement may be labelled, but the label is unnecessary unless it is
the object of a GOTO-statement.
This program segment is non-terminating and will go on asking for more
and more input, which is not quite what we intended. One method of
overcoming this is to terminate the input stream with an "impossible
number" (say, any negative number) and test for this number at the
head of the loop. When the impossible number is met, it is a signal
to go out of the main loop, print out the contents of "HIGHEST" and
terminate the program.
Using this technique, the whole program is:
line no.
--------
BEGIN INTEGER PRESENT, HIGHEST; 1
READ: PRESENT := ININT; 2
IF PRESENT < 0 THEN GOTO PRINT; 3
IF PRESENT > HIGHEST THEN HIGHEST := PRESENT; 4
GOTO READ; 5
PRINT: OUTTEXT ("THE HIGHEST VALUE = "); 6
OUTINT (HIGHEST, 3); 7
END 8
Sample data set
---------------
input: 14 63 17 -2
-----
output: THE HIGHEST VALUE = 63
------
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 11
CHAPTER 1.1
The unexplained lines are:
line 1: INTEGER PRESENT, HIGHEST
declares two variables identified by PRESENT and HIGHEST. The key
word INTEGER gives the type of these variables and introduces a
measure of security into the language.
INTEGER variables may only hold whole numbers. Other types include
REAL (for fractional numbers), BOOLEAN (which can only take the values
TRUE and FALSE) ...... By giving variables types we have the
possibility to spot such errors as
PRESENT := TRUE (TRUE is not an INTEGER value)
or
IF HIGHEST THEN .... (HIGHEST can not have the
value TRUE or FALSE).
On declaration, variables take initial values according to their type.
INTEGER variables take the value 0, REAL variables 0.0 and BOOLEAN
variables FALSE. The initial values of other types will be noted when
they are introduced.
line 3: IF PRESENT < 0 THEN GOTO PRINT
transfers control to the statement labelled "PRINT" if the input value
is negative. Otherwise the next statement to be executed is that on
line 4.
line 6: OUTTEXT ("THE HIGHEST VALUE = ")
causes the text constant to be output - text constants are enclosed in
double quotes (") so that there can be no confusion between, for
example
"12" a text constant 12 a number
"END" a text constant END a key word
This program takes the form of a block. Writing a typical declaration
as "D", and a typical statement as "S", then a block has the form
BEGIN D; D; .....; D; S; S; S; .....; S; END
Notice that declarations are always grouped at the head of a block and
the statements (actions upon them) come afterwards. As semicolons are
used to terminate the various components of the block, it is thus
possible to make the text visually clear and as appealing as possible
by aligning, putting labels well to the left, etc.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 12
CHAPTER 1.1
The program just written was not carefully planned - it was built up
atom by atom and fitted together. This is reflected in the final
result which is awkward to follow. For programs to be easily read and
understood it is essential to decompose the problem into its distinct
components and then decompose these still further into smaller
components, until the atoms of the problem are reached. In this way a
clear overall framework is guaranteed. A fresh set of actions for
this problem could be planned by splitting the problem into two phases
as follows:
read/compute ; write
which leads directly to a formulation along the lines
FOR PRESENT := next value WHILE PRESENT not negative DO
replace HIGHEST by PRESENT if PRESENT is the greater;
WRITE (HIGHEST)
Expressed in SIMULA, the corresponding program is:
line no.
--------
BEGIN INTEGER PRESENT, HIGHEST; 1
FOR PRESENT := ININT WHILE PRESENT >= 0 DO 2
IF PRESENT > HIGHEST THEN HIGHEST := PRESENT; 3
OUTTEXT ("THE HIGHEST VALUE = "); 5
OUTINT(HIGHEST,9); 6
END 7
The only new feature is the FOR-statement spanning lines 2-3.
This FOR-statement is a control statement used for organising a
repetition while a condition is met (PRESENT >= 0, PRESENT greater
than or equal to 0). The general form is:
FOR assignment WHILE condition DO
controlled-statement
which is understood as follows:
F1: the assignment is made (PRESENT := ININT)
F2: if the condition is TRUE the controlled statement (line 3) is
executed, and then control returns back to F1 (the next value
is read in ...). If the condition is FALSE, control leaves
the FOR-statement and the statement following the controlled
statement (line 4) is executed.
The comments in parentheses refer to the given example.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 13
CHAPTER 1.1
When the source program has been compiled and execution begins, an
instance of the program block is created, the data spaces created,
their values initialized according to their type and then execution of
their actions begins. A convenient picture of a block instance is:
----------------
! RTS info !
----------------
! declarations !
----------------
! actions !
----------------
Some aspects of the RTS info (run time system information) will be
explained later.
When the actions are executed, each occurrence of an identifier in the
actions may be considered matched with the occurrence of the same
identifier in the block instance head, as below:
------------------------
! RTS info !
------------------------
! INTEGER PRESENT 0 !
! !
! INTEGER HIGHEST 0 ! <----
------------------------ !
! ! !
! FOR PRESENT :=... ! >----
------------------------
(In practice, the matching is mostly done in the compile step to
minimize running-time, but conceptually we may think of the matching
as a look-up among the declared variables as illustrated in the
figure). This method of matching is known as the Binding Rule for
variables. (It is extended later). It follows that all such
quantities must be declared and that an identifier can be declared
only once in any block. By picturing block instances in this fashion,
these points seem very obvious.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 14
CHAPTER 1.2
1.2 NUMBERING A CROSSWORD PUZZLE
----------------------------
Suppose we are given an N x N crossword puzzle filled with blank and
blocked off out squares and are faced with the problem of locating and
numbering those squares from which words can begin.
e.g. ---------------------
! ! ! !!!!! !
! 1 ! ! 2 !!!!! 3 !
! ! ! !!!!! !
---------------------
! !!!!! ! ! !
! !!!!! 4 ! ! !
! !!!!! ! ! !
---------------------
! !!!!! !!!!! !
! !!!!! !!!!! !
! !!!!! !!!!! !
---------------------
! ! ! ! ! !
! 5 ! 6 ! ! 7 ! !
! ! ! ! ! !
---------------------
! ! ! ! ! !
! 8 ! ! ! ! !
! ! ! ! ! !
---------------------
A little testing by hand will soon show that an across clue can begin
if three consective squares have the pattern
A: -----------------
!!!!! ! !
!!!!! ^ ! !
!!!!! ! ! !
-------!---------
!
across clue can begin here
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 15
CHAPTER 1.2
and a down clue where three consecutive squares have the pattern
-----
!!!!!
!!!!!
B: -----
! !
! <-!--- down clue can begin here
! !
-----
! !
! !
! !
-----
Thus by sweeping through the board and matching patterns, all the
clue-starting squares can be found. This pattern matching fails if
part of either pattern A or B falls outside the board, which can
happen only if the centre square is matched with an edge square of the
board, as below:
+++++ B
+++++
+++++
oooooooooooo+++++oooo
o o o + + o
o o o + + o
A +++++++++++++ooo+++++oooo
+++++ + + + + o
+++++ + + + + o
+++++++++++++ooo+++++oooo
o o o o o o
o o o o o o
ooooooooooooooooooooo
o o o o o o
o o o o o o
ooooooooooooooooooooo
o o o o o o
o o o o o o
ooooooooooooooooooooo
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 16
CHAPTER 1.2
Instead of complicating the program by making the edges a special
case, it is much easier to extend the crossword by blocked out squares
all the way round its edge.
0 ------- N+1
**************
**************
**************
*** ***
*** 1----N ***
*** ***
*** ***
**************
**************
**************
In this way, the method of matching patterns holds good for every
square in which we are interested except for one special case. This
is when a blank square is surrounded by blocked out squares:
*****
*****
*****
***** *****
***** *****
***** *****
*****
*****
*****
which for obvious reasons does not seem to occur in practice. Its
occurrence is not catered for in our program, but it is a simple
matter to allow for it.
The representation of the crossword needs some background explanation.
When a mathematician is engaged on a problem concerned with a single
triangle, there is a strong possibility of his identifying the sides
of the triangle by "a", "b" and "c". When faced with a problem
involving many triangles, the method of identification will usually
change to the use of subscripted variables, naming the sides of the
first triangle "a1", "b1", "c1", of the second "a2", "b2",
"c2", ... of the j'th. "aj", "bj", "cj", etc. Besides saving the
trouble of inventing many unique names, the notation also invites the
grouping of like data under one identifier. The notation is easily
extended - if we require variables with two, or
three, .... subscripts, we simply write
b c
i,j i,j,k ...
respectively, using commas to separate out the various components.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 17
CHAPTER 1.2
In programs demanding the storage of much data of the same type, it is
inconvenient to declare variables one at a time, and the concept of an
ARRAY is introduced to allow the simultaneous specification of many
variables all of the same type and with the same identifier,
distinguishable only through the use of "subscripts". We can not use
the matematician's notation of subscripted variables as it occupies
more than one physical line.
But we can write on one line and separate out the identfier and the
components by use of square brackets '[' and ']'. In this way, the
mathematical
A B C
I I,J I,J,K
are written as:
A[I] B[I,J] C[I,J,K]
respectively.
When an array is declared, the following information is needed:
1. an identifier for the array,
2. the type of the array, which fixes the type of each component,
3. how many distinct variables the declaration involves. This can
be found by giving the range of each subscript.
A simple array declaration is
INTEGER ARRAY LONGSIDE[0:6]
which gives for use seven subscripted variables, each of type INTEGER
and each initialized to zero. They may be referred to as
LONGSIDE[0], LONGSIDE[1], ....., LONGSIDE[6]
To make the use of subscripted variables flexible, one is allowed to
write arithmetic expressions in the subscript positions, so that if
I = 2, for example, then LONGSIDE[2*I] and LONGSIDE[4] refer to the
same quantity.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 18
CHAPTER 1.2
A CHARACTER ARRAY is used to represent the crossword. A blank is
represented by the CHARACTER constant ' ' and a blocked out square by
'*'. The declaration of the ARRAY is:
CHARACTER ARRAY CWORD [0:N+1, 0:N+1]
representing the crossword (dimensions 1 through N), and the rim
(dimensions 0 and N+1). This will make available (N+2)^2 variables of
type CHARACTER each initialized to the initial value ' ', binary zero
(CHAR(0)). N.B. several CHARACTERS are not visible when
printed - this is one of them.
The strategy is (in words):
1. N, the number of rows and columns of the crossword itself is
given on the first input line
2. Read in the data - each row being represented on a fresh input
line
Characters may be read in one by one by successive calls on
INCHAR.
C := INCHAR
will assign the current input character to C and make the next
character the new current. In this way, repeated calls on INCHAR
successively sweep across the input line.
3. Scan through the crossword along each internal row in turn and
match the patterns A and B on each internal square. If a match
is found, print out the row number, column number and serial
number of the corresponding clue.
This prosaic description suggests the planning stages:
read in the crossword;
scan through the crossword and write where necessary;
read in the crossword;
----------------------
This planning stage is itself further divisible into two parts:
set the rim values; read the internal values;
which are discussed in turn.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 19
CHAPTER 1.2
set the rim values;
-------------------
The rim may be divided into four parts, each of N+1 squares as
shown:
ROWNO = 0
COLNO = 0 --> N
!
!
-----V-------------------------
! ! !
! ! !
-----------------------! !
! ! ! !
! ! ! !
ROWNO = 1 -> N + 1 --> ! ! <----ROWNO = 0 ->N
COLNO = 0 ! ! ! ! COLNO = N + 1
! ! ! !
! ! ! !
! ! ! !
! !------------------------
! ! !
! ! ^ !
! ! ! !
---------------!---------------
!
ROWNO = N + 1
COLNO = 1 -> N + 1
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 20
CHAPTER 1.2
This leads to the formulation:
FOR ROWNO is 0 through N DO
CWORD[0,ROWNO] := '*';
CWORD[ROWNO,N+1] := '*';
CWORD[N+1,ROWNO+1] := '*';
CWORD[ROWNO+1,0] := '*';
read the internal values;
-------------------------
For the kernel position 1 through N, this is:
FOR ROWNO is 1 through N DO
next input line;
sweep across the row for COLNO is 1 through N
and at each stage read in the next character
and assign it to CWORD [ROWNO, COLNO];
But the controlled statement can just as well be written by using a
FOR-statement:
FOR ROWNO is 1 through N DO
next input line;
FOR COLNO is col 1 through N DO
CWORD [ROWNO, COLNO] := INCHAR;
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 21
CHAPTER 1.2
Scan Through the Crossword and Write Where Necessary;
-----------------------------------------------------
This stage consists of scanning the crossword and matching patterns.
If the current square is not a blank, it can not start a clue and may
be skipped.
FOR ROWNO is 1 through N DO
FOR COLNO is 1 through N DO
IF CWORD [ROWNO, COLNO] = ' ' THEN
IF pattern A fits or pattern B fits THEN
WRITE (ROWNO, COLNO, serial number)
We are now in a position to write the program.
Program:
-------
We can not start the program by:
BEGIN INTEGER N;
CHARACTER ARRAY CWORD [0:N+1, 0:N+1];
N := ININT;
.....
because the block is created and initialized before any actions are
executed. Thus, the array bounds will not have the desired value as
N=0 at this time.
Again,
BEGIN INTEGER N;
N := ININT;
CHARACTER ARRAY CWORD [0:N+1, 0:N+1];
.....
is illegal as the declarations are not grouped at the head of the
block.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 22
CHAPTER 1.2
The way out is to create an inner block thus:
BEGIN INTEGER N;
N := ININT;
BEGIN CHARACTER ARRAY CWORD [0:N+1, 0:N+1];
.....
END;
END
An inner block is counted as a special type of statement, so that the
outer block has the form:
BEGIN declaration
statement; (N := ININT)
statement; (inner block)
END
which is legal.
The whole program is:
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 23
CHAPTER 1.2
line no.
--------
BEGIN INTEGER N, EDGE; 1
N := ININT; EDGE := N+1; 2
BEGIN INTEGER ROWNO, COLNO, SERIALNO; 3
CHARACTER ARRAY CWORD[0:EDGE, 0:EDGE]; 4
COMMENT ***WE NOW OUTPUT THE HEADING*** ; 5
OUTTEXT ("CROSSWORD NUMBERING"); 6
OUTIMAGE; 7
OUTTEXT (" ROW COL SER.NO"); OUTIMAGE; 8
COMMENT ***THE READING PHASE FOLLOWS - 9
EACH ROW IS ON A NEW CARD*** ; 10
FOR ROWNO := 0 STEP 1 UNTIL N DO 11
CWORD[0, ROWNO] := CWORD[ROWNO, N+1] := 12
CWORD[N+1, ROWNO+1] := CWORD[ROWNO+1, 0] := '*'; 13
FOR ROWNO := 1 STEP 1 UNTIL N DO 14
BEGIN INIMAGE; 15
FOR COLNO := 1 STEP 1 UNTIL N DO 16
CWORD[ROWNO, COLNO] := INCHAR; 17
END; 18
COMMENT ***THE NUMBERING PHASE FOLLOWS*** ; 19
FOR ROWNO := 1 STEP 1 UNTIL N DO 20
FOR COLNO := 1 STEP 1 UNTIL N DO 21
IF CWORD[ROWNO, COLNO] = ' ' THEN 22
BEGIN IF (CWORD[ROWNO, COLNO-1] = '*' AND 23
CWORD[ROWNO, COLNO+1] = ' ') 24
OR (CWORD[ROWNO-1, COLNO] = '*' AND 25
CWORD[ROWNO+1, COLNO] = ' ') THEN 26
BEGIN SERIALNO := SERIALNO+1; 27
OUTINT(ROWNO, 5); 28
OUTINT(COLNO, 5); 29
OUTINT(SERIALNO, 8); 30
OUTIMAGE; 31
END; 32
END; 33
END; 34
OUTTEXT ("CROSSWORD DIMENSION = "); 35
OUTINT (N, 2); 36
OUTIMAGE; 37
END 38
In which the variable EDGE has been used to avoid repeated evaluation
of N+1. Descriptive text has been inserted between the symbol COMMENT
and the succeeding semicolon. A comment is not executed - it serves
to make the program more understandable.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 24
CHAPTER 1.2
Sample data:
Input: 7
....... (dot '.' denotes space)
.*.*.*.
.....*.
.*..**.
...*...
.*...*.
.......
Output:
CROSSWORD NUMBERING
ROW COL SER.NO
1 1 1
1 3 2
1 5 3
1 7 4
3 1 5
3 4 6
4 3 7
5 1 8
5 5 9
6 3 10
6 4 11
7 1 12
CROSSWORD DIMENSION = 7
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 25
CHAPTER 1.2
Discussion
----------
The new features are considered in the order of their textual
appearance:
line no
-------
5 Descriptive text may be inserted between the key word
COMMENT and the next semicolon.
11 When a piece of program is to be repeated a known number of
times a second type of FOR-statement may be used. This is:
FOR controlled-variable := A1 STEP A2 UNTIL A3 DO
controlled-statement
where A1, A2, A3 are arithmetic expressions. Here the
controlled-statement is executed N+1 times with ROWNO taking
the values 0, 1, 2, ....., N in turn.
12 This is an example of a multiple assignment statement. It
is equivalent to
BEGIN CWORD[ROWNO+1, 0] := '*';
CWORD[N+1, ROWNO+1] := CWORD[ROWNO+1, 0];
CWORD[ROWNO, N+1] := CWORD[N+1, ROWNO+1];
CWORD[0,ROWNO] := CWORD[ROWNO, N+1];
END
but is more readable.
15 INIMAGE
which skips to the beginning of the next input line.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 26
CHAPTER 1.2
23-25 OR and AND
which are used in conditions.
C1 OR C2 OR ... OR CN
is TRUE if any of the conditions C1, C2, ... CN are TRUE,
otherwise it is FALSE.
C1 AND C2 ... AND CN
is TRUE only if every one of the conditions C1 through CN is
TRUE.
In the given example which is of the type
(C1 AND C2) OR (C3 AND C4)
parantheses have been used to group C1 AND C2 as one
subexpression, C3 AND C4 as another. Parentheses can be
used to group expressions of any type.
27-32 A grouping of the form
BEGIN statement;
statement;
statement;
END
is called a compound-statement and is yet another form of
statement. If the FOR-statement of lines 14-18 had been
written:
FOR ROWNO := 1 STEP 1 UNTIL N DO
INIMAGE;
FOR COLNO := .....
then only the input statement INIMAGE would be executed N
times before passing on to the next statement
FOR COLNO :=
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 27
CHAPTER 1.2
When the program is executed, the RTS initially creates only the outer
block. A visualisation of this outer block is:
-------------------
! !
! RTS information !
! !
-------------------
! !
! INTEGER N 0 !
! INTEGER EDGE 0 !
! !
-------------------
! !
current -----> ! N := ININT !
statement ! EDGE := N + 1 !
! <INNER BLOCK> !
! OUTTEXT ... !
! OUTINT (N,2) !
! OUTIMAGE !
-------------------
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 28
CHAPTER 1.2
At this stage only the two variables declared in the outer block, i.e.
N and EDGE exist. The inner block is created when the third statement
is encountered. Assuming an input value for N of 7, the new snapshot
when the inner block has been created is:
-------------------
! !
! RTS information !<--------
! ! !
------------------- ! TEXTUAL LINK
! ! ! to textually
! INTEGER N 7 ! ! enclosing block.
outer block ! INTEGER EDGE 8 ! !
! .... ! !
! ! !
--->! <INNER BLOCK> ! !
! ! .... ! !
! ! ! !
! ------------------- !
! !
! !
! !
! !
! ------------------------ !
! ! ! ! !
----------O ! O--------
! ! !
------------------------
! INTEGER ROWNO 0 !
! INTEGER COLNO 0 !
inner block ! INTEGER SERIALNO 0 ! -------------------
! CHARACTER ARRAY CWORD----->!Array !
! ! !character !
! ! !variables !
------------------------ !all initialized !
! ! !to "binary zero" !
current ---------->!.... ! -------------------
statement ! !
------------------------
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 29
CHAPTER 1.2
Note that the layout of all blocks is the same. We use dots ....
where the actions of blocks are irrelevant to the immediate point at
hand.
The bounds of the array are given as
[ 0 : EDGE, 0 : EDGE ]
EDGE is not defined in the inner block although it clearly exists as a
program element. Accordingly, the primitive Binding Rule for finding
meanings for identifiers given in section 1 is modified to:
1. Look in the immediate block head for a match. If found, then
that is the identifier we are after.
2. If no match is found, then continue the search via the textual
link to the textually surrounding block and try to find a match
there.
For programs with many nested blocks, step 2 is repeated until the
match is found.
When the actions of the inner block are completed, it is deleted and
control returns to the outer block resuming at its next statement
which is
OUTTEXT .....
The snapshot after return is:
-------------------
! RTS information !
-------------------
! !
! INTEGER N 7 !
! INTEGER EDGE 8 !
! .... !
! <INNER BLOCK> !
current ----->! OUTTEXT !
statement ! .... !
-------------------
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 30
CHAPTER 1.2
A more complete picture could be given as follows. On creation of the
outer block, we have:
------------------
! ! !<---
------------------ !
! ININT ! !
! INIMAGE ! !
! OUTINT ! ! RTS block
! OUTIMAGE ! !
! .... ! !
------------------ !
!
!
!
!
------------------ !
! ! ! !
! ! O----------
! ! !
------------------
! INTEGER N 0 !
! INTEGER EDGE 0 ! program outer block
current ----->! N := ININT 0 !
statement ! ..... !
------------------
which shows that the standard system procedures for input and output
(many more will be given later) are found in the normal way, and that
all the user-defined blocks collapse in the same way. We shall not
use this more complete snapshot in the future (just to save space),
but it is as well to remember its significance.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 31
CHAPTER 1.3
1.3 GEOMETRIC APPLICATIONS
----------------------
As an illustration of how SIMULA allows for concept description we
turn to the problem of automatic drawing - where the program describes
and generates figures, and their plotting is done mechanically. (It
is beyond our scope to define the last stage). We consider the task
of generating the following figure for output:
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * * * *
* * * * *
* * * * *
* * * * *
* * *
* * *
* * *
* * *
The program can be decomposed into 4 stages:
1. classification
--------------
What are the components in the program - such as points,
lines, circles?
2. generation
----------
Generate representations of these components:
L Right leg
1
L Left leg
2
L Vertical bar
3
C Circle
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 32
CHAPTER 1.3
3. assemble the figures
--------------------
Link the components together into a figure
F
\
\
>L1--->L2--->L3--->C
4. output
------
Plot the figure.
The complete program introduces several new features which are
introduced as needed.
Classification and generation
-----------------------------
To describe compound patterns such as points, lines and circles, we
build upon the most general concept we have met so far - the block. A
block is a description of a structure and it written, in general, by
BEGIN declarations; actions; END
When a block instance is generated its actions are executed and when
they are exhausted that instance is deleted never to reappear.
Here we have a need to describe patterns for points, lines and circles
and create instances of them which remain available. We need that
ability to create representations of several points, several
lines, ..... to build up the figure. It is essential that once
created their structures remain available, and so they will have to be
given names so that they may be referred to.
These are achieved in SIMULA by the CLASS and REFerence variable
concepts.
Example:
-------
The following program generates the representations of two points
R(2,0) and S (which is displaced from R by (-1,2)) and the line L
through S with length 2 and at an angle of 45 degrees to the positive
x-axis.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 33
CHAPTER 1.3
Figure:
------
Y *
^ *
! *
2 + *
! S
!
1 +
!
-2 -1 ! 1 2
-----+----+----!----+----*----->
! R X
!
!
!
!
!
Program
-------
line no.
--------
BEGIN CLASS POINT(X,Y); REAL X,Y; 1
BEGIN ................ END; 2
CLASS LINE(P,LENGTH,ANGLE); REF(POINT) P; 3
REAL LENGTH, ANGLE; 4
BEGIN ................ END; 5
REF(POINT)R,S; REF(LINE)L; 6
R :- NEW POINT (2,0); 7
S :- NEW POINT (R.X-1,R.Y+2); 8
L :- NEW LINE (S,2,45); 9
............ 10
END 11
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 34
CHAPTER 1.3
SNAPSHOT IMMEDIATELY BEFORE THE PROGRAM END
-------------------------------------------
-------------------
! ! !
---->! POINT1 ! PB !
! ! ! !
! -------------------
------------------- ! ! !
! ! ! ! ! REAL X 2 !
! PB ! . ! ! ! REAL Y 0 !
! ! ! ! ! !
------------------- ! -------------------
! ! !
! CLASS POINT ! !
! CLASS LINE ! ! -------------------
! REF (POINT) R .-!------- ! ! !
! REF (POINT) S .-!---------->! POINT2 ! PB !<---
! REF (LINE) L .-!------- ! ! ! !
! ! ! ------------------- !
! L :- ..... ! ! ! ! !
! ! ! ! REAL X 1 ! !
current ! ! ! ! REAL Y 2 ! !
--->! ..... ! ! ! ! !
statement ! ! ! ------------------- !
------------------- ! !
! !
! ------------------- !
! ! ! ! !
---->! LINE1 ! PB ! !
! ! ! !
------------------- !
! ! !
! REF (POINT) P .-!----
! REAL LENGTH 2 !
! REAL ANGLE 45 !
! !
-------------------
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 35
CHAPTER 1.3
N.B. to save a multitude of links, we have adopted the following
notation for the RTS information at the head of each block:
------------------------------------
! Name of this ! Name of textually !
! block ! enclosing block !
------------------------------------
so that
------------------------
! POINT 1 ! PB !
------------------------
means: this is the first POINT to be created, and the textual link
is to the block named PB, i.e. the actual program block.
Notice also the way the parameters are transmitted. The REAL (1)
parameters, a copy of the value of actual parameter is made local to
the object. The REF(POINT) variable in the line object, the reference
value of the actual parameter (the object POINT2) is copied. Any
succeeding operation on a parameter works with these local copies.
-------------
(1) This also holds for INTEGER, BOOLEAN and CHARACTER variables - the
so-called value types.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 36
CHAPTER 1.3
Discussion
----------
The declaration of a class may take the forms (rather simplified):
1) CLASS A (formal parameters); specifications;
BEGIN declarations;
actions;
END
or, if it has no parameters,
2) CLASS B;
BEGIN declarations;
actions;
END
If the class has parameters then each one must have its type
specified. The specifications may be in any order. Instances of the
classes may be generated by
1) NEW A (actual-parameters)
Where the actual parameters correspond in number, order and type to
those in the declaration, or
2) NEW B
When a class instance (henceforth "an object" for distinction) is
generated, its parameter values are transferred, its actions executed
and then control returns to its place of generation. Then its
whereabouts (a reference to it) may be assigned so that the object has
an identification and it may be accessed.
e.g. in R :- NEW POINT (2,0)
the reference value of the POINT object is assigned to R after it has
been generated.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 37
CHAPTER 1.3
Parameters and declarations together are called attributes. The
attributes of an object may be accessed from inside the object by
their identifier. From without, the object must be named first
followed by a separating dot ('.') then the attribute, as
R.X REAL X - coordinate of the POINT R
L.P REF(POINT) quantity, the point of application of L.
Note that from the program block there are two references to the
second point (POINT 2) - either S or L.P. It follows that the
attributes of S may be referred to as
S.X or L.P.X, and
S.Y or L.P.Y
from the program block.
Reference variables are given a qualification for security reasons.
For example, if R is REF(POINT) and L is REF(LINE) then:
R.X is valid as R is REF(POINT) and POINT objects have an
attribute X. Further the type of R.X is REAL.
L.P is valid and is of type REF(POINT)
but neither R.P nor L.X will be valid bacause R can never reference an
object having a P attribute (and similarly for L.X). By designing
SIMULA in this way, illegal attempts at accessing can be detected as
early as possible - i.e. at compile time.
At run time, errors can still occur - for example, if R references no
object (NONE) and a request for R.X occurs. NONE clearly has no
attributes. To guard against such errors two reference comparators ==
and =/= are a part of SIMULA.
R == S is TRUE only if both R and S reference the same object, or
both reference NONE.
The opposite holds for R =/= S.
One can now test
IF R =/= NONE THEN R.X := ......
ELSE OUTTEXT ("R IS CURRENTLY NONE")
and use the ELSE option to give a suitable warning message or
alternative action.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 38
CHAPTER 1.3
The initial value of all REF variables is NONE, i.e. no object.
Before proceeding to outline the assembly stage, we take time to
introduce another concept - that of a PROCEDURE.
A common task in manipulating lines is to rotate a line through a
certain number of degrees. To generate a new LINE referenced by L2
which "rotates" L1 through say 75 degrees, we could write
L2 :- NEW LINE(L1.P,L1.LENGTH,L1.ANGLE+75)
which is both tedious to write and not very clear. The PROCEDURE
concept enables us to write
L2 :- L1.ROTATED(75)
by defining a suitable PROCEDURE "ROTATED" as a part of the body of
CLASS LINE.
The PROCEDURE must do the following:
1) generate a new LINE object
2) pass as parameters the POINT and LENGTH attributes of L1 (it
is L1's attribute ROTATED so these are available directly),
and add 75 to the ANGLE of L1
3) return a reference to the new LINE object
CLASS LINE is now written:
CLASS LINE(P,LENGTH,ANGLE); REF(POINT)P;
REAL LENGTH,ANGLE:
BEGIN REF(LINE) PROCEDURE ROTATED(THETA); REAL THETA;
ROTATED :- NEW LINE(P,LENGTH,ANGLE+THETA);
END
The PROCEDURE concept enables common action clusters to be designed
and tested as components, and replaces many actions by a single
identifier. This makes programs easy to decompose and considerably
more readable.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 39
CHAPTER 1.3
Procedures are used in two senses: either as statements, such as
OUTTEXT("THE HIGHEST VALUE = ")
or INIMAGE ,
or as values, as in
PRESENT := ININT
or L2 :- L1.ROTATED(90)
In both cases, the procedure is activated by the occurrence of its
identifier and actual parameters (if any). If the procedure is to be
used as a statement then its declaration has the form
PROCEDURE identifier; PROCEDURE-body
or PROCEDURE identifier parameter-description
PROCEDURE-body
where a PROCEDURE-body is a statement.
If the PROCEDURE is to return a value then the procedure is given a
type and the value to be returned is assigned to a special variable of
that type by the actions of the PROCEDURE-body.
e.g.
REF(LINE)PROCEDURE ROTATED(THETA); REAL THETA;
ROTATED :- NEW LINE(P,LENGTH,ANGLE+THETA)
where the result is assigned to a REF(LINE) variable "ROTATED" inside
the PROCEDURE-body.
On activation of a procedure, copies of the values of the actual
parameters are transferred to the procedure if the "modes" part is
empty (as here). A rather different method of parameter transmission
(by NAME) is also available for procedures and its use will be
explained shortly.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 40
CHAPTER 1.3
Assemble the figures
--------------------
The grouping of the lines and circles into figures is not trivial
because:
- figures can have a variable number of components
- the type of components varies (it can either be REF(LINE) or
REF(CIRCLE)).
One neat way of assembling the components is by using a stack. In a
stack, each piece of information is stored on the top and pushes
previous members lower down. Ignoring the qualification aspect for
the moment, we can picture a stack S before and after a new member has
been inserted by:
before
------
--- ---
S !---->!2!------>!1!
--- ---
---
!3!
---
after
-----
--- --- ---
S !---->!3!------->!2!------->!1!
--- --- ---
Whatever object is stacked, the actual mechanism for so doing is the
same. It follows that we should be able to isolate stackable
qualities, define them, and be able to build them onto other concepts.
The concept of stackable needs one reference variable "NEXT" to
reference the next lower member of the stack (or NONE if the bottom
member). So we can begin with the outline:
CLASS STACKABLE;
BEGIN REF(?) NEXT; .......... END
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 41
CHAPTER 1.3
To build stackability into information carrying objects such as LINES
and CIRCLES, we use a prefix notation and write their class
declarations as:
CLASS STACKABLE ......;
STACKABLE CLASS LINE ...........;
STACKABLE CLASS CIRCLE .........;
Now LINE and STACKABLE objects have the appearances:
------------------ ------------------
! ! ! ! ! !
------------------ ------------------
prefix * REF ( ? ) NEXT * * REF ( ? ) NEXT *
------------------ ------------------
! !
! REF (POINT) P !
main ! !
part ! REAL LENGTH !
! !
! REAL ANGLE !
------------------
LINE OBJECT STACKABLE OBJECT
In other words, LINE objects now have the concept of stackability
built into them.
We are now in a position to resolve the question of the qualification
of NEXT. Clearly, if we have a stack then each object in the stack
must have a STACKABLE part or else it could not be inserted. If we
define NEXT to have the qualification REF(STACKABLE), we are then sure
that each variable "NEXT" in the stack chain will reference either
NONE or else an object which is at least "STACKABLE sized". This does
mean that we have to relax our strict rules of referencing to allow
the NEXT variables to reference any member of a class prefixed by
STACKABLE. Let us see how this works. Suppose we have:
BEGIN REF(STACKABLE)ST;
REF(LINE)L;
L :- NEW LINE(NEW POINT(0,0), 1,0);
ST :- L;
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 42
CHAPTER 1.3
The assignments are valid but the range of direct attribute accessing
is restricted to the qualification level of the reference variable
concerned.
----------------------------
! ! !
----------------------------
ST---->! REF (STACKABLE) NEXT !
----------------------------
! REF (POINT) P ---!------>
! REAL LENGTH 1.0 !
L ---->! REAL ANGLE 0.0 !
----------------------------
Thus
ST.NEXT
L.ANGLE
L.LENGTH
L.P
are valid. So also is L.NEXT as, if L references an object, it must
be at least "LINE sized" and thus contain a STACKABLE part and so an
attribute NEXT. But we can not allow
ST.LENGTH ST.ANGLE ST.P
so easily, as ST may also reference STACKABLE or CIRCLE objects which
have no such properties.
On the other hand we do not wish to disallow accessing the LINE object
at the LINE level via ST - what we do is to make it manifest that we
are entering a LINE object by requiring the user to write
ST QUA LINE.P
ST QUA LINE.LENGTH
ST QUA LINE.ANGLE
This enables compile time checking: "ST QUA LINE" - can ST reference
a LINE object ? Yes, as its qualification is REF(STACKABLE) and
STACKABLE prefixes LINE. ST QUA LINE.P - have LINE OBJECTS AN
ATTRIBUTE "P" ? YES.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 43
CHAPTER 1.3
Before writing the actual program, we take time to introduce the
concept of call by NAME. Suppose we wish to insert a LINE object (L)
and CIRCLE object (C) into a stack (ST).
The coding is:
L.NEXT := ST;
ST :- L;
COMMENT ***NOW L IS INSERTED*** ;
C.NEXT :- ST;
ST :- C;
COMMENT ***NOW C IS INSERTED***;
Snapshots before and after the insertion of L are:
before
------
----------
! !
ST .---->! . !
! !
----------
! !
! !<--- Z
! !
----------
----------
! !
L ---->! . !
! !
----------
! !
! !
! !
----------
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 44
CHAPTER 1.3
after
-----
----------
! !
---->! . !
ST . ! ! !
! ! ----------
! ! ! !
! ! ! !<--- Z
! ! ! !
! ! ----------
V !
----------
! ! !
! . !
! !
----------
! !
L ---->! !
! !
----------
The coding is a repeat except for a parameter saying which object is
to be inserted. The PROCEDURE concept enables us to give CLASS
STACKABLE procedure attribute "INTO", and then we can write
L.INTO (ST)
C.INTO (ST)
for the same effect. This is not only more concise, but more readable
than before. This time we have to be rather careful about how the
parameter is transmitted. It is the purpose of the procedure to
actually alter the value of the variable ST itself to reference not
its current value Z but the new entry. In other words, we do not want
to operate upon the value of ST (its object reference) but manipulate
variable ST itself. This can be done by specifying the parameter to
be called by NAME, as follows. The new definition of CLASS STACKABLE
is:
CLASS STACKABLE;
BEGIN REF(STACKABLE)NEXT;
PROCEDURE INTO(H); NAME H; REF(STACKABLE)H;
BEGIN NEXT :- H;
H :- THIS STACKABLE;
END;
END
(The new keyword THIS refers to the "local object", i.e. L if we call
L.INTO, and C if we call C.INTO).
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 45
CHAPTER 1.3
It is worthwhile spending extra time to show how the NAME parameter
mechanism works. Consider the program skeleton:
BEGIN CLASS STACKABLE...........;
STACKABLE CLASS LINE......;
REF(LINE)L,Z;
REF(STACKABLE)ST;
..........
COMMENT ***L AND Z ARE NOW GENERATED, AND Z
SET "INTO" ST*** ;
L.INTO(ST)
END
A snapshot before the call is made is:
----------------------
! PB ! !
----------------------
! CLASS STACKABLE !
! CLASS LINE ! -----------
! REF (STACKABLE) ST-!----->! L1 ! PB !
! ! ! ! !
! REF (LINE) Z-------!----->-----------
! REF (LINE) L-------!--- ! NEXT !
---------------------- ! ! INTO !
! -----------
!
! -----------
--->! L2 ! PB !
-----------
! NEXT !
! INTO !
-----------
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 46
CHAPTER 1.3
After activation of the procedure, we have:
---------------------- --------------
! PB ! ! ---->! L1 ! PB !
! ! ! ! ! !
---------------------- ! !->--------------
! CLASS STACKABLE ! ! ! ! NEXT NONE !
! CLASS LINE ! ! ! ! INTO !
! REF (STACKABLE) ST-!-- ! --------------
! REF (LINE) Z-------!----
! REF (LINE) L-------!-- --------------
! ... ! !--->! L2 ! PB !<---
! L.INTO(ST) ! -------------- !
---------------------- ! NEXT NONE ! !
^ ! INTO ! !
! -------------- !
! !
! -------------- !
! ! ! .--!----
! --------------
---------------!--H !
! NEXT :- H !
! H :- THIS !
--------------
Note the textual links of the various blocks - those of the LINK
objects are to the program block, that of the procedure block is to
the object referenced by L (i.e. L2). H is not given a value but a
link back to the actual parameter. Every occurrence of H means
"re-evaluate the corresponding quantity".
For the first statement:
NEXT :- H
NEXT is found by the normal binding rule in the block L2 (it is L's
NEXT) and this is set to reference H. But H is called by NAME, so the
actual parameter corresponding to H is looked up and its current value
returned. This is assigned to NEXT.
The next statement
H :- THIS STACKABLE
assigns a reference to the "nearest" STACKABLE object (the one to
which the procedure is textually linked) to H. But again H is called
by NAME and so this means assigning to ST the object L2.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 47
CHAPTER 1.3
These statements are then equivalent to
NEXT :- ST;
ST :- THIS STACKABLE;
Another way of explaining call by NAME is to say that every occurrence
of the formal parameter is textually replaced by the actual parameter
in the procedure instance.
The program:
-----------
We aim to produce the following structure prior to plotting:
--------
DRAW ------->! NEXT-!----
-------- !
! ! !
! ! !
L1 -------- !
!
!
--------<---
! NEXT-!----
-------- !
! ! !
! ! !
L2 -------- !
!
!
--------<---
! NEXT-!----
-------- !
! ! !
! ! !
L3 -------- !
!
!
--------<---
! NEXT !
--------
! !
! !
C --------
The following concepts are needed
STACKABLE
POINT
LINE
CIRCLE
- once these have been defined we can proceed with object generation.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 48
CHAPTER 1.3
Outlines of the classes are
CLASS STACKABLE;
BEGIN REF(STACKABLE)NEXT;
PROCEDURE INTO ............;
END;
STACKABLE CLASS LINE(P,LENGTH,ANGLE);
REF(POINT)P; REAL LENGTH,ANGLE;
BEGIN .............................. END;
STACKABLE CLASS CIRCLE(CP,RAD);
REF(POINT)CP; REAL RAD;
BEGIN .............................. END;
CLASS POINT(X,Y); REAL X,Y;
BEGIN ................ END;
The components are:
* * *
* * *
* * *
* * *
* * L *
* * 3 *
* * * C
* * * * *
* L * * * L *
* 2 * * * 1 *
* * * * *
* * *
* * *
* * *
* * *
and one piece of coding to generate them could be:
ORIGO :- NEW POINT(0,0);
L1 :- NEW LINE(ORIGO,1,-45);
L2 :- NEW LINE(ORIGO,1,225);
L3 :- NEW LINE(NEW POINT(0,-1),2,90);
C :- NEW CIRCLE(ORIGO,1);
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 49
CHAPTER 1.3
Although this coding is quite terse, we can in fact make it much more
readable by use of procedures local to classes POINT and LINE.
Defining suitable procedures, we can replace the above coding by:
ORIGO :- NEW POINT(0,0);
L1 :- ORIGO.RAY(1,-45);
L2 :- L1.ROTATED(-90);
L3 :- NEW POINT(0,-1).RAY(2,90);
C :- ORIGO.RING(1);
The clearness of this piece of program means that it is not only easy
to read and understand, but also easy to write. From a wider point of
view this is ideal because it invites draughtsmen who are not (expert)
programmers to use the concepts we have developed.
We explain only one of the procedures RAY, ROTATED, RING as they are
fairly similar. Let us choose "RING".
ORIGO.RING(1)
has replaced the original
NEW CIRCLE(ORIGO,1)
and must, therefore, achieve the same effects. These are:
1. generate a new CIRCLE object
2. set in ORIGO and 1 as actual parameter values
3. return a reference to the new CIRCLE object.
The procedure is written local to class POINT and is available through
the dot notation. The declaration of CLASS POINT becomes:
CLASS POINT(X,Y); REAL X,Y;
BEGIN REF(CIRCLE) PROCEDURE RING(R); REAL R;
RING :- NEW CIRCLE(THIS POINT,R);
END
This procedure is given the type REF(CIRCLE) as it is to return a new
CIRCLE object as value. The type of the calling expression
ORIGO.RING(1)
is REF(CIRCLE). THIS POINT is a reference to the POINT object to
which the PROCEDURE RING is an attribute, in this case ORIGO.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 50
CHAPTER 1.3
The whole program is:
line no.
--------
BEGIN CLASS PLOTTING; 1
BEGIN CLASS STACKABLE; 2
BEGIN REF(STACKABLE)NEXT; 3
PROCEDURE INTO(H); NAME H; REF(STACKABLE)H; 4
BEGIN NEXT :- H; 5
H :- THIS STACKABLE; 6
END ***OF INTO*** ; 7
END *STACKABLE*** ; 8
CLASS POINT(X,Y); REAL X,Y; 9
BEGIN REF(LINE) PROCEDURE RAY(L,A); REAL L,A; 10
RAY :- NEW LINE(THIS POINT,L,A); 11
REF(CIRCLE) PROCEDURE RING(R); REAL R; 12
RING :- NEW CIRCLE(THIS POINT,R); 13
END ***OF POINT*** ; 14
STACKABLE CLASS LINE(P,LENGTH,ANGLE); REF(POINT)P; 15
REAL LENGTH,ANGLE; 16
BEGIN REF(LINE) PROCEDURE ROTATED(THETA); 17
REAL THETA; 18
ROTATED :- NEW LINE(P,LENGTH,ANGLE+THETA); 19
IF P == NONE OR LENGTH <= 0 THEN 20
BEGIN OUTTEXT("BAD POINT"); 21
OUTIMAGE; 22
END; 23
END ***OF LINE*** ; 34
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 51
CHAPTER 1.3
STACKABLE CLASS CIRCLE(CP,RADIUS); REF(POINT)CP; 25
REAL RADIUS; 26
BEGIN IF CP == NONE OR RADIUS <= 0 THEN 27
BEGIN OUTTEXT("BAD CIRCLE"); 38
OUTIMAGE; 29
END; 30
END ***OF CIRCLE*** ; 31
PROCEDURE PLOT ......; 32
REF(STACKABLE)DRAW; 33
REF(POINT)ORIGO; 34
ORIGO :- NEW POINT(0,0) 35
END ***OF PLOTTING*** ; 36
PLOTTING BEGIN REF(LINE)L1,L2,L3, 37
REF(CIRCLE)C; 38
GENERATE: INSPECT ORIGO DO 39
BEGIN L1 :- RAY(1,-45); 40
L2 :- L1.ROTATED(-90); 41
L3 :- NEW POINT(0,-1).RAY(2,90); 42
C :- RING(1) 43
END; 44
ASSEMBLE: C.INTO(DRAW); 45
L1.INTO(DRAW); 46
L2.INTO(DRAW); 47
L3.INTO(DRAW); 48
PLOT; 49
END ***OF PREFIXED BLOCK*** ; 50
END 51
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 52
CHAPTER 1.3
Discussion
----------
line no
-------
1-36 Defines the concepts needed for the plotting of figures as
CLASS PLOTTING.
- stacking lines 2-8
- points lines 9-14
- lines lines 15-24
- circles lines 25-31
- plot line 32
and contains as actions the generation of the origin line
35. Note that LINE and CIRCLE are prefixed by STACKABLE and
that their definitions contain actions which will give a
warning message if the objects under generation are badly
described.
37-50 PLOTTING is used to prefix a block. When this block is
entered all the concepts of PLOTTING are available for use,
and the user operates in a built in environment.
39-44 The construction
INSPECT X DO statement
is another method of accessing objects. If X == NONE the
statement is skipped, otherwise an attribute A of the object
X is available without the need to write X.A.
Here RING(1) is equivalent to ORIGO.RING(1) written outside
this construction as ORIGO has an attribute RING. On the
other hand, as ORIGO has no attribute L1, L1 stands for the
REF(LINE) quantity declared in line 37.
49 The plotting procedure is called and the appropriate output
displayed.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 53
CHAPTER 1.4
1.4 SIMULATION OF A QUEUING SITUATION
---------------------------------
We can best motivate the need for, and uses of, simulation by means of
an example. Consider the case of a garage owner who has installed an
automatic car wash which services cars one at a time. As his
efficiently run service gets more and more popular, the owner is faced
with a dilemma. As more customers use the car wash their average
waiting time will tend to increase and the service becomes less
attractive. The owner may now react in two ways - build further car
washes which will keep the present customers happy (and probably
attract more), or do nothing and let the customer flow stabilize
itself at a lower level. As the building of further car washes
entails considerable expense, this is not a decision to be taken
lightly and demands some investigation.
It is at this point that simulation can help. Simulation is a
technique for representing a dynamic system by a model and
experimenting with the model in order to gain information about the
system. The approach is useful if the system is not amenable to
analytic techniques and direct experimentation with the system (such
as building the car washes and seeing what happens) is impractical.
Car Wash Simulation
-------------------
Suppose the car wash services cars one at a time and each service
takes 10 minutes. When a car arrives it goes straight into the car
wash if the latter is standing idle, otherwise it must wait in the
queue. As long as cars are waiting, the car wash is in continuous
operation serving on the first-come, first-served principle.
If the arrival times of the cars have been recorded for one day then a
very simple model is capable of reproducing the essential aspects of
the system on that day. This model can generate data which describes
the performance of the installation - such as use of equipment,
average number of waiting cars, time spent by each car.
The operation of the system consists of two critical events:
1. THE ARRIVAL OF A CAR. The arrival time is noted. If the car
wash is idle a ten minute service starts at once. Otherwise
the car goes to the end of the queue.
2. END OF SERVICE. The elapsed time for that car is noted and
the car leaves the system. If cars are waiting, the first
one in the queue is served and another 10 minute service is
started. Otherwise the machine becomes idle.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 54
CHAPTER 1.4
The car wash, of course, starts in the idle state and awaits the first
arrival.
In order to understand the model better, we consider a trace of
history of the model over a short period when cars arrive at the times
(in minutes) 6, 10, 13, 28, 42, 43, 48. The state of the model only
changes at the two critical times noted above: when a car arrives,
when a service is finished. Accordingly we need only trace at these
times.
Car wash trace
--------------
time event
---- -----
0 the car wash awaits the first arrival
6 car 1 arrives and goes into the car wash
10 car 2 arrives and must wait
13 car 3 arrives and waits in the queue
16 car 1 leaves the system
car 2 is served
26 car 2 leaves the system
car 3 enters the car wash
28 car 4 arrives and waits in the queue
36 car 3 leaves the system
car 4 enters the car wash
42 car 5 arrives and must wait
43 car 6 arrives and must wait
46 car 4 leaves the system
car 5 enters the car wash
48 car 7 arrives and must wait
56 car 5 leaves the system
car 6 enters the car wash
66 car 6 leaves the system
car 7 enters the car wash
76 car 7 leaves the system
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 55
CHAPTER 1.4
The data recorded by the cars is:
Car 1 2 3 4 5 6 7
Arrival 6 10 13 28 42 43 48
Departure 16 26 36 47 56 66 76
Elapsed time 10 16 23 18 14 23 28
Average time spent is 132/7 = 18.8 minutes
By comparing these results with those from the actual system, it can
be verified that the model is sufficiently accurate. The management
wishes to reduce the average time spent. The model can be used again,
this time with two car washes operating on the same data. We add the
decision rule that machine 1 should be used if both are idle. The
results of the trace are:
Car 1 2 3 4 5 6 7
Arrival 6 10 13 28 42 43 48
Departure 16 20 26 38 52 53 62
Elapsed time 10 10 13 10 10 10 14
Served by
machine 1 2 1 1 1 2 1
Average time spent is 77/7 = 11 minutes
For this sample, then, the average time spent waiting in the queue
prior to service is reduced from nearly 9 minutes to 1 minute by the
building of an extra car wash. Note how important it is to have both
models working on exactly the same data.
Clearly no management should base its decisions upon such a small
sample. To arrive at better estimates it is necessary to simulate the
system for several days. If the necessary data cannot be collected,
it may be appropriate to use a statistical model to represent the
arrival of the cars. (Moreover the characteristics of the car arrival
process - i.e. the customer behavior - may vary with the service
capacity as well as with other future changes in the car washing
market).
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 56
CHAPTER 1.4
The CLASS SIMULATION
--------------------
SIMULA is provided with a predefined system CLASS SIMULATION, which
contains all the necessary concepts for queues and active and passive
components.
When the identifier SIMULATION is used to prefix a block these
concepts become available to the user. (The details are not given
here).
There are three CLASSES within SIMULATION of prime importance:
PROCESS - which is used to prefix classes whose objects have
active and passive phases.
LINK - which prefixes classes whose objects are to be placed
in, and removed from, queues.
HEAD - which serves as the head of a queue
N.B. PROCESS is itself prefixed by LINK, so that PROCESS objects have
the queue membership attributes.
The program for one car wash
----------------------------
One can view the system with the cars as passive objects being pushed
through the system by the car wash. The outline of CLASS CAR is
LINK CLASS CAR (NUMBER); INTEGER NUMBER;
BEGIN record entry time;
go into queue;
IF car wash idle THEN ACTIVATE car wash;
END
Prefixing the CLASS with LINK gives each CAR object the ability to be
placed in a queue.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 57
CHAPTER 1.4
Having recorded the entry time, the CAR object goes in at the end of
the queue. (If the car wash is idle then this means that this CAR is
the first member of the queue). If the car wash is idle it is
activated (whereupon it services the first member in the queue), if
the car wash is not idle then this CAR awaits its turn.
PROCESS CLASS WASH (QUEUE); REF(HEAD)QUEUE;
BEGIN
SERVE: take the first car out of the queue;
service it for ten minutes;
record the serviced car's exit time;
send the car out of the system;
IF the queue is empty THEN PASSIVATE;
GOTO SERVE;
END
By prefixing CLASS WASH with "PROCESS", WASH objects are given the
ability to be active components in the SIMULATION. The initially idle
WASH object is activated by the first car.
The active cycle of a car wash starts by taking the first CAR out of
the queue. After a ten minute pause, the serviced CAR has its exit
time recorded (the present simulation time) and is despatched from the
system. If the queue is not empty, these actions are repeated (GO TO
SERVE), otherwise the machine becomes idle (PASSIVATE) and is
activated by the next CAR's arrival, whereupon the cycle starts again.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 58
CHAPTER 1.4
The complete program is:
line no.
--------
SIMULATION 1
BEGIN LINK CLASS CAR (NUMBER); INTEGER NUMBER 2
BEGIN INTEGER INAT; 3
INAT := TIME; 4
INTO(CARWASH.QUEUE); 5
IF CARWASH.IDLE THEN ACTIVATE CARWASH; 6
END ***OF CAR*** ; 7
PROCESS CLASS WASH(QUEUE); REF(HEAD)QUEUE; 8
BEGIN REF(CAR)SERVED; 9
SERVE: SERVED :- QUEUE.FIRST 10
SERVED.OUT; 11
HOLD(10); 12
INSPECT SERVED DO 13
BEGIN OUTINT(NUMBER, 10); 14
OUTINT(INAT, 10); OUTINT(TIME, 10); 15
OUTINT(TIME-INAT, 10); 16
OUTIMAGE; 17
END; 18
SERVED :- NONE; 19
IF QUEUE.EMPTY THEN PASSIVATE; 20
GOTO SERVE 21
END ***OF WASH***; 22
REF(WASH)CARWASH; 23
INTEGER I,J,U; 24
CARWASH :- NEW WASH(NEW HEAD); 25
U := ININT; 26
J := ININT; 27
OUTTEXT(" SIMULATION OF ONE CAR WASH"); 28
OUTIMAGE; 29
OUTTEXT(" CAR NO. INTIME OUTTIME ELAPSED TIME"); 30
FOR I := 1 STEP 1 UNTIL J DO 31
BEGIN NEW CAR(I); 32
HOLD(POISSON(12,U)); 33
END; 34
HOLD(10000); 35
END 36
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 59
CHAPTER 1.4
Sample input:
------------
3 100
Segment of output:
-----------------
SIMULATION OF ONE CAR WASH
--------------------------
CAR NO. INTIME OUTTIME ELAPSED TIME
1 0 10 10
2 14 24 10
3 29 39 10
4 37 49 12
5 50 60 10
6 67 77 10
7 81 91 10
8 96 106 10
9 108 118 10
10 121 131 10
11 131 141 10
12 142 152 10
13 154 164 10
14 163 174 11
15 180 190 10
16 186 200 14
17 194 210 16
18 208 220 12
19 218 230 12
20 233 243 10
21 252 262 10
22 256 272 16
23 263 282 19
24 273 292 19
25 287 302 15
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 60
CHAPTER 1.4
Discussion:
----------
Line
----
1 The program block is prefixed by CLASS SIMULATION which
gives the programmer the predefined concepts of queues,
and PROCESS objects which can be active or passive.
2-36 The user-defined program
2-7 CLASS CAR is defined. Each CAR is distinguished by its
NUMBER. On generation of a CAR
3 The entry time is recorded. "TIME" is a system defined
procedure returning the current system time.
4 The CAR enters the queue as last member. INTO is a
procedure property of all LINK objects.
5 If the car wash is idle then it is activated. IDLE is
another system defined procedure, local to all PROCESS
objects.
This is the last action of a CAR object, thereafter it
is pushed through the system by the WASH.
8-22 CLASS WASH is defined.
9 SERVED is used to reference the currently serviced car.
10-11 When the car wash is made active it starts to serve the
next car, SERVED is set to reference the next candidate
for service and that car is removed from the queue.
12 HOLD(T) is a call on a system procedure which suspends
the actions of the car wash (in this case) for a length
of time T.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 61
CHAPTER 1.4
13-18 The car wash is active again, 10 minutes later. The
relevant data is output.
19 The only reference to the CAR SERVED is lost - it
disappears from the simulation.
20 If the queue is empty, the car wash becomes idle
(passivates itself). It will only become active on
command from the next car.
21 The actions are repeated.
25 A WASH object is generated and referenced by CARWASH.
It has a NEW HEAD as parameter (which serves to hold
the waiting CAR objects).
27-30 N, the number of CAR objects to be generated, is read
in, and suitable text headings are output.
31-34 J new CAR objects are generated and automatically enter
the queue. In between the generation of successive
objects, the program holds itself, "reappearing" after
a time delay taken from a POISSON distribution. The
standard random drawing procedures available in SIMULA
are fully discussed in Appendix B.
35 Having generated the last car, the program suspends
itself for a sufficiently long time to make sure that
they have all been serviced.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 62
CHAPTER 2
CHAPTER 2 THE SYNTAX AND SEMANTICS OF SIMULA
---------------------------------------------
2.1 METHOD OF SYNTAX SPECIFICATION
------------------------------
When a SIMULA construction and all its variants can not be
economically described in words, its exact range will be shown using a
system of notation which is standard throughout Part 2.
The notation is not in itself a part of SIMULA, nor restricted solely
to SIMULA. It may be used to describe the syntax (or allowable
constructions) of any programming language, and provides a compact,
visually clear and precise explanation of the general patterns that
the language permits. It is important to realise that it does not
describe the meaning of these constructions (their semantics), only
their structure. In other words, it indicates:
- the order in which language elements may or must be combined
with each other,
- the punctuation that is required, and
- the full range of options.
No such convenient shorthand is yet available for the semantics, so
that interpretation of a legal construction has to be described in
words.
We begin by noting that various patterns of basic symbols continually
recur in SIMULA. Instead of repeating the listing of the basic
symbols each time, they are first grouped together as a named
syntactic variable, and from then on we need use only that name. The
idea extends itself that further syntactic variables may now be
defined in terms of those already defined and possibly basic symbols.
The SIMULA basic symbols are represented by special characters, such
as
+ / ) ; ^
by combinations of special characters, such as
:- ** =/=
and by key words in capital letters, such as
PROCEDURE CLASS REAL BEGIN
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 63
CHAPTER 2.1
When we define a syntactic variable, its name will usually be written
in lower case letters for distinction:
e.g block statement digit
A certain ambiguity can arise when the name of a syntactic variable
consists of two words, such as
prefixed block
To ensure that these are interpreted as one syntactic unit and not for
example, an occurrence of a syntactic variable named "prefixed"
followed by a syntactic variable named "block", a hyphen is inserted
between the words, as:
prefixed-block
In certain cases, when a basic symbol is an integral part of a
syntactic variable, it is clearer to use upper-case letters. Again,
we avoid possible ambiguities by following the upper-case letters by a
hyphen:
e.g. FOR-statement GOTO-statement
We now give two examples to show the uniqueness of interpretations
using this technique:
1. IF BOOLEAN-expression THEN
denotes an occurrence of the basic symbol "IF" followed by a
"BOOLEAN-expression" followed by an occurrence of the basic
symbol "THEN".
2. REF(CLASS-identifier)
denotes an occurrence of the basic symbol "REF" followed by
an occurrence of the left parenthesis "(" followed by a
"CLASS-identifier" followed by an occurrence of the right
parenthesis ")". The separation between "REF" and "(" occurs
because if a basic symbol is a key word it may only be
composed of letters.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 64
CHAPTER 2.1
Bearing these in mind, the following rules explain the use of the
notation as applied to SIMULA.
1. A syntactic variable is a general class of elements in
SIMULA. The name of the syntactic variable must consist of:
A. lower-case letters
lower-case letters separated by hyphens
lower-case letters followed by a digit
e.g. identifier
compound-statement
identifierl
simple-object-expression
B. a combination of upper-case letters and lower-case
letters. There must be one portion of all upper-case
letters and at least one portion of all lower-case
letters separated, one from another, by hyphens:
e.g. PROCEDURE-statement
All such units used in this section are defined either
formally using this notation or else in words.
2. A basic symbol denotes an occurrence of the characters
represented. A basic symbol is either a key word or else one
or more special characters
e.g. BEGIN END
+ =/=
N.B. When a basic symbol consists of more than one character
no intervening spaces may appear.
Thus, for example,
BEG IN =/ =
are both faulty representations.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 65
CHAPTER 2.1
3. The term syntactic unit, which is used in subsequent rules,
is defined by
A. a single syntactic variable or basic symbol, or
B. any collection of syntactic variables, basic symbols,
syntax-language symbols (the symbols [, ], ,...
whose uses are defined in subsequent rules) surrounded by
braces or brackets.
Examples:
digit letter
[digit]
[letter]
digit
digit ...
** **
4. Braces ** ** are used as group markers.
** **
Example: the definition of an object-relation is
object-relation
---------------
** **
* IN *
simple-object-expression ** ** CLASS-identifier
* IS *
** **
The vertical stacking of syntactic units indicates the range
of available choices of which exactly one must be taken. The
example shows that in an "object-relation", a
"simple-object-expression" must be followed by the literal
occurrence of either "IN" of "IS" (but not both) and then by
a "CLASS-identifier".
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 66
CHAPTER 2.1
5. The exclamation point ! indicates alternatives.
Example: the definition of a digit is
digit
-----
0!1!2!3!4!5!6!7!8!9
This has the same interpretation as
** **
* 0 *
* 1 *
* 2 *
* 3 *
** 4 **
* 5 *
* 6 *
* 7 *
* 8 *
* 9 *
** **
but saves considerable space. Both the methods, rule 4
(** **) and rule 5 ( ! ) are used in this manual to
display alternatives. We will usually stick to the use of
braces as this notation is clearer, and use ! only when the
former notation takes up too much space.
6. Square brackets [ ] denote options. Anything enclosed in
square brackets may appear once or not at all.
Examples: the definition of a CLASS-declaration is
CLASS-declaration
-----------------
[CLASS-identifier] main-part
This denotes a syntactic unit "main-part" optionally preceded
by a "CLASS-identifier".
If alternatives are also optional, we use vertical stacking
within the square brackets.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 67
CHAPTER 2.1
Thus the much simplified version of an activation-statement
ACTIVATE [ BEFORE Y ]
[ AT time [PRIOR] ]
would allow the following alternatives:
ACTIVATE X
ACTIVATE X BEFORE Y
ACTIVATE X AT time
ACTIVATE X AT time PRIOR
7. Three dots ... denote the occurrence of the immediataly
preceding grouping one or more times in succession, i.e. a
repetition.
Examples:
The definition of digits is:
digits
------
digit ...
denoting the occurrence of at least one digit such as
1
0935
1976
The definition of a compound-statement is:
compound-statement
------------------
BEGIN [statement ;]... [statement] END
(The statement preceding END may be terminated by a
semicolon; DUMMY-statement)
Examples;
BEGIN END
BEGIN ; END
BEGIN statement END
BEGIN statement ; END
BEGIN statement;
statement;
statement;
END
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 68
CHAPTER 2.2
2.2 BASIC SYMBOLS AND SYNTACTIC VARIABLES
A program written in SIMULA may contain only
basic symbols
identifiers
constants
Apart from CHARACTER-constants, TEXT-constants and comments where
extra latitude is allowed, a program must contain only characters
belonging to the language character set. These are either
alphanumeric characters, special symbols or key words. Examples of
special symbols are
+ - ( ) [ ]
which have obvious interpretations. In addition, SIMULA needs many
other special symbols and, instead of using peculiar combinations of
special characters for their representation, SIMULA uses key words
such as BEGIN, CLASS. These key words are reserved within the
language and may be used only as key words.
2.2.1 LANGUAGE CHARACTER SET
The SIMULA basic symbol set is built up from a character set of
alphabetic-characters, decimal-digits and special-characters.
There are 52 international alphabetic-characters - the upper and lower
case letters A through Z, a through z. DECsystem-10 SIMULA also
regards the swedish letters AA (A with a circle), AE (A with two
dots), OE (O with two dots) as alphabetic (see below). Except in
certain constants, the upper and lower case version of the same
letters are interpreted as identical.
There are 10 decimal-digits - the digits 0 through 9.
An alphanumeric-character is either an alphabetic character or a
decimal digit.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 69
CHAPTER 2.2.1
The special-characters may have an independent meaning within the
language (such as + or -) or may be used in combinations (such as :=
or =/=). Their names and the graphics by which they are represented
are:
name graphic
---- -------
blank or space
plus +
minus -
asterisk or multiply *
divide /
equals =
greater than >
less than <
not \ (alt. representation "NOT")
comma ,
dot or period .
exponent &
colon :
semicolon ;
uparrow ^
left parenthesis (
right parenthesis )
character quote '
text quote "
underscore -
left square bracket [
right square bracket ]
exclamation sign !
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 70
CHAPTER 2.2.1
The swedish letters AE AA OE ae aa oe correspond to the following
international equivalents:
Swedish International Octal Decimal
letter symbol rank rank
--------------------------------------------
AA $ 044 36
AE # 043 35
OE @ 100 64
aa } 175 125
ae { 173 123
oe ` 140 96
!! IMPORTANT !!
The use of these characters in
identifiers does not agree with the
standard definition of the SIMULA
programming language. Programmers are
therefore advised not to use these
letters in identifiers. If you use
them, note that all lower case letters
in identifiers are interpreted by the
compiler identical to the corresponding
upper-case letter, ae is thus
interpreted as AE, aa as AA and oe as
OE.
A full description of the DECsystem-10 SIMULA character set is given
in appendix A to the DECsystem-10 SIMULA Language Handbook part I.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 71
CHAPTER 2.2.2
2.2.2 BASIC SYMBOLS
Any program written in SIMULA may contain only alphanumeric
characters, the special characters and device control characters (like
tab and formfeed), except within CHARACTER- or TEXT-constants and
comments (see DATA CHARACTER SET section 2.3). Certain combinations
of these allowable characters have special significance and are called
basic symbols.
They fall into two classes:
delimeters
key-words
delimiters
----------
The delimiters used by the language are divided into 6 types:
1. Arithmetic-operators
2. Logical-operators
3. Brackets
4. Reference-comparators
5. Relational-operators
6. Separators
1. Arithmetic-operators
The arithmetic-operators are:
+ denoting addition or unary plus
- denoting subtraction or unary minus
* denoting multiplication
/ denoting division
^ or ** denoting "raised to the power of"
// denoting integer division
2. Logical-operators
The five logical-operators denoting NOT, OR, AND, EQV and IMP
(the last two representing equivalence and implication
respectively) are represented by key words. In the case of
NOT there is the alternative representation '\'.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 72
CHAPTER 2.2.2
3. Brackets
The brackets are:
The brackets
( )
are used in expressions, for enclosing parameter lists and
for array and switch bounds and indices, the square brackets
[ ]
only be used for array and switch bounds and indices.
' encloses character constants
" encloses text constants
4. Reference-comparators
The reference-comparators are:
== denoting reference equal to
=/= denoting reference not equal to
5. Relational-operators
The relational-operators have dual representations as key
words and symbol combinations
= (or EQ) denoting equal to
\= (or NE) denoting not equal to
> (or GT) denoting greater than
>= (or GE) denoting greater than or equal to
< (or LT) denoting less than
<= (or LE) denoting less than or equal to
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 73
CHAPTER 2.2.2
6. Separators
name graphic use
---- ------- ---
comma , separating elements in lists
dot . denoting decimal point in REAL
numbers; remote accessing
colon : follows labels; follows VIRTUAL;
separates array bounds in array
declarations
becomes := in value assignments
denotes :- in reference assignments
semicolon ; separates declarations and
statements; separates various parts
of procedure and class headings
exclamation mark ! may be used instead of COMMENT to
indicate the start of a comment
blank used as a separator
underscore _ used in identifiers (e.g.
RATE_OF_PAY)
( ) & power-of-ten symbol in REAL and
10 LONG REAL constants.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 74
CHAPTER 2.2.2
key-words
---------
A key-word is an identifier which is a part of the language and its
use is reserved for that purpose. Key-words may be classified as
follows: (1)
1. Statement-brackets
2. Declarators
3. Specificators
4. Operators
5. Key-word-constants
1. Statement-brackets
The statement-brackets are:
BEGIN
END
which are used to demark the limits of blocks and compound
statements.
2. Declarators
The declarators are:
BOOLEAN
CHARACTER
INTEGER
SHORT INTEGER
REAL
LONG REAL
TEXT
REF (CLASS-identifier)
CLASS
PROCEDURE
SWITCH
ARRAY
which are used in declarations and specification lists. The
key words SHORT and INTEGER, LONG and REAL must be separated
by at least one space, as
SHORT .[...] INTEGER
LONG .[...] REAL
-------------
(1) In addition to this, the word OPTIONS is a reserved word in
DECsystem-10 SIMULA and is used in the OPTIONS statement to give certain
machine-dependent information to the system (e.g. if you want a source
program listing or not, if you want to generate symbol tables for the
SIMULA Debugging System or not etc.). For further information about the
OPTIONS statement see the DECsystem-10 SIMULA Language Handbook part II.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 75
CHAPTER 2.2.2
3. Specificators
The specificators are:
HIDDEN
LABEL
NAME
PROTECTED
VALUE
VIRTUAL
which are used in specification parts to procedures (LABEL,
NAME, VALUE) or to classes (VALUE, VIRTUAL, HIDDEN,
PROTECTED).
4. Operators
The operators are divided into 4 classes:
logical-operators
relational-operators
sequential-operators
special-operators
The logical-operators are:
AND denoting the logical and
OR denoting the logical inclusive or
NOT (or \) denoting logical negation
EQV denoting logical equivalence
IMP denoting logical implication
The relational-operators are:
EQ (or =) denoting equal to
NE (or \=) denoting not equal to
GT (or >) denoting greater than
GE (or =) denoting greater than or equal to
LT (or <) denoting less than
LE (or <=) denoting less than or equal to
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 76
CHAPTER 2.2.2
The sequential-operators are:
GOTO
used in GOTO-statements. GOTO may also be written
GO ... TO (with any number of blanks between GO and TO,
which means that GO and TO both are reserved words),
FOR
STEP
UNTIL
WHILE
DO
used in WHILE- and FOR-statements (DO also appears in
connection-statements),
IF
THEN
ELSE
used in conditional-statements and
conditional-expressions,
INSPECT
WHEN
DO
OTHERWISE
used in connection-statements. (DO also appears in
WHILE- and FOR-statements),
ACTIVATE
REACTIVATE
DELAY
AFTER
BEFORE
AT
PRIOR
used in activation-statements,
INNER
used in CLASS-bodies to alter the order of execution of
statements from their textual order,
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 77
CHAPTER 2.2.2
The special-operators are:
NEW
is used in generating objects,
THIS
THIS CLASS-identifier represents a reference to the
nearest textually enclosing object of a class equal to or
inner to that of the CLASS-identifier,
QUA
defines the scope of a reference expression,
IS
IN
used to test class membership,
COMMENT or !
used to insert descriptive text among the basic symbols
of a program.
The key-word-constants are:
TRUE
FALSE
represent logical values,
NONE
represents the "no object reference",
NOTEXT
represents "no text object", i.e. the empty text.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 78
CHAPTER 2.2.3
2.2.3 DATA CHARACTER SET
Although the language character set is a fixed set defined for the
language, the data character set has not been limited. Data may be
represented by characters from the language set plus any other
ISO-7(ISO R 646) characters.
Collating sequence
------------------
The 128 members of the data character set have associated with them a
unique INTEGER value in the range 0-127. This sequence is known as
the collating sequence. It is thus possible to make comparisons of
CHARACTERs meaningful by comparing the associated numerical values,
such as
'A' < 'B'
INCHAR = ' '
Parts of the collating sequence are given in Appendix A.
2.2.4 THE USE OF BLANKS
Identifiers, composite operators (e.g. =/=), key words (e.g. BEGIN)
may not contain blanks. Blanks are permitted as CHARACTER-constants,
in TEXT-constants and in arithmetic constants.
Identifiers, constants and key words may not be immediately adjacent.
They must be separated by an arithmetic operator, parenthesis
( () [ or ] ), reference comparator, negation (\), non-key-word
relational operator (<,<=,=,\=,>,>=,==,=/=), comma, dot, colon,
becomes symbol (:=), denotes symbol (:-), semicolon, or blank.
Moreover additional intervening blanks are always permitted.
Examples:
X + Y is equivalent to X+Y
A [I ] is equivalent to A[I]
A :=X :=Y is equivalent to A:=X:=Y
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 79
CHAPTER 2.2.5
2.2.5 COMMENT CONVENTIONS
Comments are used for documentation (the insertion of a textual
description of part of the program) and do not participate in the
execution of a program. The following conventions hold:
Sequence of basic symbols
-------------------------
The sequence: ! is equiv. to:
!
** ** !
** ** * any sequence from * !
* COMMENT * * the data character . * !
Delimiter ** ! ** ** set not including ** ;! Delimiter
* * * a semicolon * !
** ** ** ** !
!
** ** !
* any sequence from the data * !
END ** character set not including ** ! END
* END!ELSE!WHEN!OTHERWISE!; * !
** **
Examples:
1. BEGIN COMMENT***THE NEXT BLOCK IS USED FOR PAY-ROLL
CALCULATIONS***;
BEGIN .....
.....
END OF PAY-ROLL BLOCK;
.....
END
WHERE THE STRINGS "COMMENT .... ;" and "OF PAY-ROLL BLOCK" are treated
as comments.
2. IF X > 0 THEN BEGIN .....
END OF TRUE PART
ELSE BEGIN .....
END OF FALSE PART;
WHERE THE STRINGS "OF TRUE PART" and "OF FALSE PART" are treated as
comments.
3. X := X !THAT WAS X;**2 COMMENT**SQUARED;;
is equivalent, as regards program execution, to
X := X**2;
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 80
CHAPTER 2.2.5
2.2.6 CODING SIMULA PROGRAMS
A SIMULA source program on the DECsystem-10 may contain lines with up
to 135 characters. The lines may be line-numbered in the standard
DECsystem-10 way. Some of the lines in a line-numbered source program
may have blank line numbers.
If you convert SIMULA source programs from a system which expects the
source program in columns 1-72, you should remove columns 73-80. (You
can use PIP, the IBMSIM, or the CDCSIM program to do this.)
This will be described in greater detail in DECsystem-10 SIMULA
Language Handbook Part II.
2.3 IDENTIFIERS
-----------
An identifier is a string of alphanumeric or underscore characters,
not contained in a comment or constant, preceded and followed by a
delimiter - the initial character must be a letter.
identifier
----------
letter[ letter ! digit ! _ ]...
Examples:
valid identifiers
-----
X
SIMULA_67
A15
MORGAN_PLUS_4
invalid identifiers
-------
END reserved for use as a keyword
SYM BOL contains a blank
3C does not begin with a letter
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 81
chapter 2.3
Length of identifiers
---------------------
Identifiers in a SIMULA program may be composed of any number of
alphanumeric or underscore characters, but in DECsystem-10 SIMULA only
the first twelve are significant. Thus if two identifiers contain the
same first twelve characters they are considered equivalent.
e.g. BIORTHOGONAL and
BIORTHOGONALISATION
will both be treated as occurrences of the identifier
BIORTHOGONAL
NOTE ! THE USE OF DIFFERENT EXTERNAL IDENTIFIERS (PROCEDURES or
CLASSES) which are equivalent in the first six characters is not
recommended.
Identifiers and key words
-------------------------
It is not possible to use a key word as an identifier. Every
occurrence would be treated as an occurrence of that key word and its
use as an identifier would result in errors.
Basic binding rules
-------------------
Variables, arrays, switches, procedures and classes are said to be
quantities. Identifiers serve to identify quantities, or they stand
as labels or formal parameters. Identifiers have no inherent meaning
and may be chosen freely (except that they may not clash with key
words).
Every identifier used in a program must be declared. This is achieved
by:
1. A declaration (section 5), if the identifier defines a
quantity. It is then said to be a J-variable, J-ARRAY,
J-PROCEDURE-, PROCEDURE-, CLASS-identifier where J stands for
the type of the declared quantity.
2. Its occurrence as a label (section 5.6) if the identifier
stands as a label. It is then said to be a LABEL-identifier.
3. Its occurrence in the formal-parameter-list (section 5.4,
5.5) of a PROCEDURE- or CLASS-declaration. It is then said
to be a formal-parameter.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 82
chapter 2.3
The identification of the definition of a given identifier is
determined by binding rules. The basic binding rules given below are
later extended in the cases of remote accessing (section 6.1), VIRTUAL
quantities (section 5.5), and connection (section 7.2).
1. If the identifier is defined within the smallest block
(section 7.1) textually enclosing the given occurrence by its
occurrence as a quantity or label, then it denotes that
quantity or label.
The statement following a procedure heading or a class
heading is always considered to be a block, which makes the
binding to formal parameters a special case.
2. Otherwise if the block is a procedure or a class body and the
given identifier is identical with a formal parameter in the
associated procedure or class heading, then it stands for
that formal parameter.
Otherwise, these rules are applied by considering the smallest block
textually enclosing the block which has been previously considered.
If these steps lead to more than one definition or to no definition,
then the identification is illegal.
Example:
line 1 BEGIN PROCEDURE A;
2 X := X + 1;
3 REAL X;
4 BEGIN REAL X;
5 X := 2;
6 LAB: A;
7 END;
8 END
The block spanning lines 4-7 is textually enclosed in the block
spanning lines 1-8. The procedure declaration of lines 1-2 is treated
as though it were
PROCEDURE A;
BEGIN <dummy-declaration>;
X := X + 1;
END;
Thus the occurrence of X at line 5 is bound to the declarations of
line 4, whereas in the invocation of the procedure at line 6 the
binding rule for the occurrence of X in the procedure body is to the
variable declared at line 3.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 83
chapter 2.4
2.4 TYPES AND CONSTANTS
-------------------
Constants and variables possess values and types. Both the value and
type of a constant are determined by the way it is written. The value
of a variable is the one most recently assigned to it, or its initial
value if no assignment has yet been made, and its type is determined
by its declaration.
2.4.1 TYPES
Type is subdivided into two classes by:
type
----
** **
* *
** value-type **
* reference-type *
* *
** **
where value-type and reference-type are defined by:
value-type
----------
** **
* [SHORT ]INTEGER *
** [LONG ]REAL **
* BOOLEAN *
* CHARACTER *
** **
reference-type
--------------
** **
* *
** REF(CLASS-identifier) **
* TEXT *
* *
** **
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 84
CHAPTER 2.4.2
2.4.2 CONSTANTS
A constant is a fixed, unvarying quantity that denotes itself, i.e.
it can not alter during the course of a program. Each constant has a
uniquely defined type. The discussion of constants follows the order:
arithmetic-constants
BOOLEAN-constants
CHARACTER-constants
object-reference-constant
TEXT-constant
Null characters (characters with RANK = 0 or RANK = 177(8) = 127(10))
are ignored wherever they appear in input source programs, and they
can thus appear anywhere within a constant.
arithmetic-constants
--------------------
Arithmetic-constants may be written with the bases 2, 4, 8, 10 or 16.
The base 10 (decimal) is assumed unless otherwise indicated. Note
that
1. The use of arithmetic-constants is optimised by the system
2. Any '+' or '-' sign preceding an arithmetic-constant is
treated separately.
decimal-constant
----------------
Decimal-constants are interpreted according to conventional notation
with '&' or '&&' representing the exponent sign. If a decimal
constant contains either a decimal point, or an exponent sign, or
both, it is interpreted as a (LONG) REAL number, if it contains
neither a decimal point nor an exponent sign, it is taken to represent
an INTEGER number.
decimal-digit
-------------
** **
* *
** 0!1!2!3!4!5!6!7!8!9 **
* *
** **
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 85
CHAPTER 2.4.2
decimal-digits
--------------
decimal-digit ...
representing a run of at least one decimal digit.
Examples:
-------- 000
1
315730
INTEGER-constant
----------------
decimal digits
The range of values is the set of whole numbers from 0 through 2^35-1
(=34 359 738 367). If the magnitude is equal to or exceeds 2^35, the
number is interpreted as a REAL constant.
Examples:
-------- 0
91
81472
[LONG]REAL-constant
-------------------
** **
* ** ** *
* * .decimal-digits * *
* ** decimal-digits.decimal-digits ** exponent *
* * decimal-digits * *
* ** ** *
** **
* .decimal-digits *
* decimal-digits.decimal-digits *
* exponent *
** **
where exponent takes the form
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 86
CHAPTER 2.4.2
exponent
--------
[+]
& [&][-]decimal-digits
i.e. the symbol '&' or '&&', optionally followed by a '+' or '-'
sign, followed by an INTEGER-constant. The exponent represents a
scale factor expressed as an integral power of 10.
The range of values of (LONG) REAL-constants is 0.147&-38 through
0.170&+39 (approximately). A true zero is also representable. The
symbol '&' indicates REAL constants, the symbol '&&' indicates LONG
REAL constants. The precision is approximately 9 decimal digits for
REAL constants and 18 decimal digits for LONG REAL constants.
Examples
--------
Valid
-----
0.0
999.999
57.6&+21 REAL
.3&1
3&1
&-1
314.1592653&&0
21.2274568&&+03 LONG REAL
Invalid
-------
3. No digit after the decimal-point
3,149.2 Embedded comma
33.4& No scale factor
23.4&87 Out of range
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 87
CHAPTER 2.4.2
Other number systems than decimal
---------------------------------
Constants may have a radix of 2, 4, 8 or 16 by putting the sequence
"nR" where n is the radix, immediately in front of the constant. For
radix 16, the letters A through F are used to represent the
hexadecimal equivalents of 10 to 15.
Examples:
16R56789 hexadecimal
16RB1FF hexadecimal
2R10110011 binary
8R7777777 octal
BOOLEAN-constants
-----------------
These are the key words FALSE and TRUE whose interpretation is
obvious.
CHARACTER-constants are represented by
-------------------
'[any one printable member of the data character set]' (1)
Examples:
Valid CHARACTER-constants:
-----
'X'
'&'
' '
''' the character quote itself
Invalid CHARACTER-constants:
-------
':-' two data character set members
'A ' blanks are significant in character constants
X no embedding character quotes
'4 no terminating character quote.
-------------
(1) By a printable character is meant a character with RANK
between 40 and 176 (octal), i.e. 32 and 126 (decimal).
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 88
CHAPTER 2.4.2
TEXT-constants have the form
--------------
"[any sequence of printable members of the data character set]"(2)
A TEXT constant can contain the device control characters VT, CR, LF
and FF, but these are not treated as part of the text constant. To
include the character " in a text constant, repeat it twice. The
length of a TEXT constant is the number of printable characters it
contains. The length may be a natural number in the range 0 through
2^15. (Note that text variables can be longer than this!) Blanks are
significant in text constants.
(However, a text variable can contain device control characters, and
it is easy to copy a text constant to a variable and then use
"T.PUTCHAR(CHAR(n))" to insert the character with RANK n (decimal)
into it.)
Examples
Valid TEXT constants
-----
"THISTEXTCONSTANTHASNOBLANKS"
"THIS ONE HAS"
"""THIS ONE BEGINS AND ENDS WITH A DOUBLE-QUOTE"""
"MULTI-" \ Equivalent to:
"LINE " - "MULTI-LINE TEXT"
"TEXT" /
Invalid TEXT constants:
-------
"ONE " TOO MANY" imbedded double-quote is not doubled
"NEVER ENDING contains no terminating double-quote
Object-reference-constant
-------------------------
There is only one object-reference-constant, namely
NONE
Any object reference variable may take the value NONE.
-------------
(2) By a printable character is meant a character with RANK
between 40 and 176 (octal), i.e. between 32 and 126 (decimal).
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 89
CHAPTER 2.5
2.5 DECLARATIONS
------------
Declarations introduce a measure of security into the language by
associating identifiers with variables, arrays, switches, procedures
and classes used in the programs.
A declaration determines the type and structure of a quantity.
Declarations must appear in a block head, and upon exit from that
block (unless it is the outermost block of a class body), they lose
their significance.
declaration
-----------
** **
* TYPE-declaration *
* ARRAY-declaration *
* SWITCH-declaration *
** PROCEDURE-declaration **
* CLASS-declaration *
* EXTERNAL-declaration *
** **
Common to each of the succeeding sections, which discuss these
declarations, is the definition of an identifier-list.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 90
CHAPTER 2.5
identifier-list
---------------
identifier [, identifier]...
in which the identifiers must all be different.
Examples:
--------
Valid
-----
AXOLOTL
A, B, MARY, B_14
Invalid
-------
A B no separating comma
A, END, Q END is a key word and is not allowed as an
identifier.
B1,B2, B1 the same identifier appears twice
BIORTHOGONAL, BIORTHOGONALISATION
the identifiers are not distinct (only the first
twelve characters are significant).
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 91
CHAPTER 2.5.1
2.5.1 TYPE DECLARATIONS
Type declarations associate each identifier in the associated
identifier list with a variable of a given type. This restricts the
range of values that may be assigned to that variable.
type-declaration
----------------
** **
* [LONG]REAL *
* [SHORT]INTEGER (3) *
* CHARACTER *
** BOOLEAN ** identifier-list
* REF(CLASS-identifier) *
* TEXT *
** **
Examples:
--------
valid:
-----
value-type REAL R1, R2
LONG REAL P1
INTEGER I, J, K
SHORT INTEGER SH1
CHARACTER A, B, C, D
BOOLEAN B1, B2, B3
reference-type REF(POINT) P, Q
TEXT MY_STRING, YOUR_STRING
invalid:
-------
SHORT REAL ONE No such type
REF LINE_1, LINE_2 No such type - the qualification
is omitted.
INTEGER and SHORT INTEGER variables may only assume whole numbers.
REAL and LONG REAL variables may only assume numbers.
-------------
(3) SHORT is included for compatibility with 360/370 SIMULA, but on the
DEC 10 both SHORT INTEGERS and INTEGERS are in fact stored in full 36 bit
words.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 92
CHAPTER 2.5.1
N.B. An arithmetic expression of any arithmetic type (SHORT INTEGER,
INTEGER, REAL, LONG REAL) may be assigned to an arithmetic variable.
If the types do not correspond, the expression is first converted to
the type of the variable and then transferred, subject to its being in
range. If it is not in range, then a run time error will result.
BOOLEAN variables may only assume the values TRUE and FALSE.
CHARACTER variables may only assume values from the data character
set.
TEXT variables may only assume strings of characters from the data
character set or NOTEXT.
REF variables may only assume the value NONE or references to objects
belonging to their qualifying class or its subclasses.
SIMULA has no built-in COMPLEX arithmetic, but it is easy to define
COMPLEX yourself as
CLASS complex(re,im);
REAL re, im;
BEGIN
REF (complex) PROCEDURE plus(arg2);
REF (complex) arg2;
BEGIN ...
END;
...
END;
Each variable declared in a type declaration has an initial value
(given in the table below). Thereafter the value of a variable is the
one last assigned to it, or if no assignment has yet been made, the
initial value.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 93
CHAPTER 2.5.1
Type Initial value Assignable range
---- ------------- ----------------
[SHORT] INTEGER 0 Whole number in the range -2^35 through
2^35-1.
[LONG] REAL 0.0 Exact 0 or +- a number in the range
0.146 936 793 852 785 939&&-38 to
0.170 141 183 460 469 231&&+39 to 9
decimal places for REAL variables and to
18 decimal places for LONG REAL
variables.
BOOLEAN FALSE TRUE, FALSE.
CHARACTER CHAR(0) CHAR(0), CHAR(1), ... CHAR(127).
REF(CLASS- NONE NONE or any object of the qualifying class
identifier) or included in the qualifying class.
TEXT NOTEXT NOTEXT or any string of characters from
the data character set of length 0
through 2^18-1 characters. The text
constant "" is identical to NOTEXT.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 94
CHAPTER 2.5.2
2.5.2 ARRAY DECLARATIONS
An array is a structure of many components (subscripted variables) all
of the same type. Each component has the same identifier (the array
identifier), and they are distinguished one from another by
subscripts. Arrays invite the user to group like data under one
identifier.
Arrays are declared with a certain shape. They can have 1 through 10
dimensions (which is the number of subscripts necessary to specify a
certain component), and each dimension has a fixed range specified by
giving an upper and lower bound.
Pictorial representations of one, two and three dimensional arrays are
now given.
One dimensional array
INTEGER ARRAY NUMBER [4:9];
-------------
! NUMBER[4] !
-------------
! NUMBER[5] !
-------------
! NUMBER[6] !
-------------
! NUMBER[7] !
-------------
! NUMBER[8] !
-------------
! NUMBER[9] !
-------------
Dimensions 1:
Lower subscript bound = 4
Upper subscript bound = 9
Declares 6 subscripted variables each of type INTEGER and initialized
to 0.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 95
CHAPTER 2.5.2
Example:
Find the sum of the components of the array NUMBER.
SUM := 0;
FOR I := 4 STEP 1 UNTIL 9 DO
SUM := SUM + NUMBER[I];
Two dimensional array
REF(POINT) ARRAY A[0:3, 2:4];
-------------------------------------
! A[0, 2] ! A[0, 3] ! A[0, 4] !
-------------------------------------
! A[1, 2] ! A[1, 3] ! A[1, 4] !
-------------------------------------
! A[2, 2] ! A[2, 3] ! A[2, 4] !
-------------------------------------
! A[3, 2] ! A[3, 3] ! A[3, 4] !
-------------------------------------
Dimensions 2:
Lower subscript bound 1 = 0
Upper subscript bound 1 = 3
Lower subscript bound 2 = 2
Upper subscript bound 2 = 4
Declares 12 subscripted variables each of type REF(POINT) and each
initialized to NONE.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 96
CHAPTER 2.5.2
Example:
Scan the array and count how many subscripted variables are currently
referencing NONE.
COUNT := 0;
FOR I := 0 STEP 1 UNTIL 3 DO
FOR J := 2 STEP 1 UNTIL 4 DO
IF A[I, J] == NONE
THEN COUNT := COUNT + 1;
Three dimensional array
BOOLEAN ARRAY B[0:2, 0:3, -1:0];
/-----------------------------------------------/
/ B[0,0,0] / B[0,1,0] / B[0,2,0] / B[0,3,0] /!
/-----------/-----------/-----------/-----------/ !
/ / / / / !
/-----------------------------------------------/ !
! B[0,0,-1] ! B[0,1,-1] ! B[0,2,-1] ! B[0,3,-1] ! !
!-----------------------------------------------! !
! B[1,0,-1] ! B[1,1,-1] ! B[1,2,-1] ! B[1,3,-1] ! /
!-----------------------------------------------! /
! B[2,0,-1] ! B[2,1,-1] ! B[2,2,-1] ! B[2,3,-1] ! /
!-----------------------------------------------!/
(Each component is represented by a cube).
Dimensions 3:
Lower subscript bound 1 = 0
Upper subscript bound 1 = 2
Lower subscript bound 2 = 0
Upper subscript bound 2 = 3
Lower subscript bound 3 = -1
Upper subscript bound 3 = 0
Scan through the array and set the values of each subscripted variable
to TRUE.
FOR I := 0 STEP 1 UNTIL 2 DO
FOR J := 0 STEP 1 UNTIL 3 DO
FOR K := -1 STEP 1 UNTIL 0 DO
B[I,J,K] := TRUE;
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 97
CHAPTER 2.5.2
ARRAY-declaration
[type] ARRAY ARRAY-segment [,ARRAY-segment]...
ARRAY-segment
identifier-list (lower-bound:upper-bound
[,lower-bound:upper-bound]...)
Examples:
ARRAY-segment A[1:10]
B,C[1:15, 0:N**2]
ARRAY-declaration ARRAY ALFA [0:N]
REF(LINE) ARRAY L,M[0:P.X]
TEXT ARRAY R,S[1:5], T[1:4,ININT:IF X=0
THEN 10 ELSE 100]
Each identifier in an array declaration is associated with an array of
a given type (if no type is given, the type is taken to be REAL). To
enable arrays of the same type, but with different shapes (number of
dimensions and subscript ranges) to be declared in the same place, an
array declaration contains one or more ARRAY-segments which are
identifier-lists followed by their common shape. The number of
dimensions is the number of upper-bound lower-bound pairs and the
range of each subscript is specified directly by the
upper-bound/lower-bound pairs taken in order.
Note that although the lower- and upper-bounds may be arithmetic
expressions their value is the rounded integer as evaluated on entry
to the block. To be valid, the value of each lower bound must be less
than or equal to the value of its associated upper bound. Neither
bound may refer to a quantity declared in the same block head. The
value of each subscripted variable is initialized according to the
type of the array.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 98
CHAPTER 2.5.3
2.5.3 SWITCH DECLARATIONS
A switch is declared with a list of designational-expressions which
are accessed by an index. The length of the list, N, gives the number
of switch elements. The value of each element is the current value of
the designational-expression (a label to a statement, or another
switch value).
SWITCH-declaration
SWITCH SWITCH-identifier := designational-expression
[,designational-expression]...
Examples:
SWITCH SW := L1, L2, T[N], M1
SWITCH T := M1, IF N<0 THEN L1 ELSE L3, M1
A SWITCH declaration contains a list of designational expressions each
of which is given a positive index (starting from 1) by counting the
items in the list from left to right. The value of the
switch-designator (see section 6.6) corresponding to a given index is
the current value of the designational expression having the index in
the corresponding list. (An expression in a switch list is
re-evaluated every time it is referred to).
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 99
CHAPTER 2.5.4
2.5.4 PROCEDURE DECLARATION
A procedure declaration defines an action cluster and gives it a
formal name. The action cluster is the body of the PROCEDURE. To
increase the generality of the concept, there are facilities for
transmitting parameters and returning a function value at run time.
Thus a procedure is able to interact with its calling environment by
bindings established by the calling mechanism.
By means of the procedure concept, special instances of declared
action clusters become meaningful units within the SIMULA program.
PROCEDURE-declaration
---------------------
** **
* proper-procedure-declaration *
** **
* function-declaration *
** **
proper-procedure-declaration
----------------------------
PROCEDURE PROCEDURE-heading PROCEDURE-body
function-declaration
--------------------
type PROCEDURE PROCEDURE-heading PROCEDURE-body
PROCEDURE-heading
-----------------
** **
* ; *
PROCEDURE-IDENTIFIER ** formal-parameter-part mode-part spec-part **
* *
** **
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 100
CHAPTER 2.5.4
formal-parameter-part
---------------------
(identifier-list); (4)
mode-part
** **
* VALUE identifier-list; *
** **
* NAME identifier-list; ... *
** **
spec-part
** **
* ** ** *
* * type * *
* * [type] ARRAY * *
* * PROCEDURE * *
** ** type PROCEDURE ** identifier-list; ... **
* * LABEL * *
* * SWITCH * *
* ** ** *
** **
procedure-body
--------------
statement
Note for identifier-list in mode-part and spec-part:
a) Only identifiers from the formal-parameter-part may appear,
b) each of those identifiers must appear only once in the mode-part
and once in the spec-part.
(4) The maximum number of parameters is 255.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 101
CHAPTER 2.5.4
Examples:
proper-procedure-declaration
----------------------------
PROCEDURE SWAP(A,B); NAME A, B;
REAL A, B;
BEGIN REAL X;
X := A;
A := B; B := X;
END ***SWAP***
PROCEDURE OUTCOLUMN(A,N); REAL ARRAY A; INTEGER N;
BEGIN INTEGER J;
FOR J := 1 STEP 1 UNTIL N DO
BEGIN OUTFIX (A[J], 5, 12);
OUTIMAGE;
END;
END ***OUTCOLUMN***
PROCEDURE TREETRAVERSE(N); REF(NODE)N;
INSPECT N DO
BEGIN TREETRAVERSE(LEFTBRANCH);
DUMP;
TREETRAVERSE(RIGHTBRANCH);
END ***RECURSIVE TRAVERSE***
A proper-procedure is used as a statement in its own right.
INIMAGE
OUTTEXT("PROPER-PROCEDURE")
IF B THEN SWAP(TEMP1,TEMP2)
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 102
CHAPTER 2.5.4
function-declaration
--------------------
REF(POINT) PROCEDURE ADD(Q); REF(POINT)Q;
IF Q =/= NONE THEN ADD :- NEW POINT(X+Q.X,Y+Q.Y)
REAL PROCEDURE NORM(A,N); REAL ARRAY A; INTEGER N;
BEGIN REAL T; INTEGER I;
FOR I := 1 STEP 1 UNTIL N DO
T := T + A[I]**2;
NORM := SQRT(T)
END ***NORM***
INTEGER PROCEDURE FACTORIAL(N); INTEGER N;
IF N < 0 THEN ERROR ELSE
IF N < 2 THEN FACTORIAL := 1
ELSE FACTORIAL := N*FACTORIAL(N-1)
A function returns a value of the type indicated in its declaration,
and may be used wherever a value of that type is legal. (It may also
be used as a statement in which case the function value is ignored);
P :- R.ADD(S)
X := NORM(MATRIX, 10)
IF NORM (MATRIX, 10) < &-6 THEN
OUTTEXT ("ELEMENTS ALL (ALMOST) ZERO")
A PROCEDURE-declaration defines a procedure associated with a
PROCEDURE-identifier. The chief component of a PROCEDURE declaration
is the PROCEDURE-body which may be activated through a
PROCEDURE-statement or a function-designator.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 103
CHAPTER 2.5.4
If the procedure has formal-parameters, then their identifiers are
listed in the formal-parameter part. No formal-parameter identifier
may appear more than once, and specifications of all formal-parameters
must be supplied. Whenever the procedure is activated by a
PROCEDURE-statement or function-designator, the formal-parameters are
either assigned the values of the actual-parameters (call by value,
call by reference) or else replaced by the actual-parameters (call by
name).
Identifiers in the PROCEDURE-body which are not formal-parameters are
local if declared within that body, otherwise they are non-local. A
PROCEDURE-body acts like a block regardless of its format.
Consequently, the scope of any label to a statement within the body or
to the body itself can never be extended beyond the PROCEDURE-body.
In addition, if the identifier of a formal-parameter is redeclared
within the PROCEDURE-body (or used as a label), it is given local
significance and the corresponding actual-parameter becomes
inaccessible.
When a PROCEDURE-declaration is given a type, it designates a
function. The type of this function is the type of the PROCEDURE and
for any activation its value is the last value assigned to an
occurrence of the PROCEDURE-identifier within the PROCEDURE-body. If
no such assignment is made, then the result of the function-designator
takes a default value which is identical to the initial value of a
declared variable of that type.
Within the PROCEDURE-body of a function-procedure, an assignment may
be made to an occurrence of the PROCEDURE-identifier. Every other use
of the PROCEDURE-identifier denotes another activation of the
procedure (recursion). Note that is perfectly legal to use a function
procedure call as a single statement (exploating it's side effects
probably). For example: "SQRT(1);" is a legal statement as well as
"LASTITEM;" (skips blanks and tabs and returns TRUE if end-of-file is
encountered - see section 3.5.)
Execution of the procedure stops when control is passed to the final
END of the procedure body. Control is thereafter returned to the
place where the procedure was called.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 104
CHAPTER 2.5.4
PARAMETER TRANSMISSION
N.B. There are three possible modes for parameter transmission
call by value
call by reference
call by name
All three are allowable for parameters to procedures, but only call by
value and call by reference are valid for parameters to classes.
Since call by value and call by reference are common to procedure and
class declarations, these sections apply to class declarations as
well.
If no mode is specified in the mode part, then the parameter is
transmitted by the appropriate default mode which is call by value for
value type parameters, and call by reference for other kinds of
parameters.
The available transmission modes for legal parameters to procedures
are shown in the following table:
PROCEDURE PARAMETERS
Parameter Transmission
by value by reference by name
value-type D X O
object-reference X D O
TEXT O D O
value-type ARRAY O D O
reference-type ARRAY X D O
PROCEDURE X D O
type PROCEDURE X D O
LABEL X D O
SWITCH X D O
D : default mode
O : optional
X : illegal
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 105
CHAPTER 2.5.4
Call by value
-------------
A formal-parameter called by value designates a local copy of the
value obtained by evaluating the actual parameter. The evaluation
takes place at the time of procedure entry. Throughout the lifespan
of the procedure or class body, the formal-parameter acts like a local
variable (or value type array (5)) and its contents may be accessed
and changed by local assignments. In the case of an object, the
contents may be accessed and changed from without by remote accessing.
Value specification is redundant for a parameter of value type. There
is no call by value option for object references, reference-type
ARRAYS, PROCEDURES, type-PROCEDURES, LABELS and SWITCHES.
Example:
Given the program:
BEGIN PROCEDURE CALL_BY_VALUE_(X,Y,T1,T2,B);
VALUE T1, T2, B;
REAL X, Y; TEXT T1, T2; BOOLEAN ARRAY B;
BEGIN .................... END;
BOOLEAN ARRAY TRUTH[0:3];
TEXT S;
REAL NUM;
NUM := 3.5; S :- COPY("+++");
TRUTH[2] := TRUE;
CALL_BY_VALUE(4,NUM,S,"O.K",TRUTH);
...
END
-----------------------------------------------------------
(5) The type of an arithmetic ARRAY passed by VALUE must be identical
to the formal type.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 106
CHAPTER 2.5.4
then a snapshot on procedure entry shows the initialized values for
the formal-parameters.
---------------------------
! ! !
! BLOCK ! !<---
! ! ! !
!-------------------------! !
! ! ! ---------
! PROCEDURE CALL_BY_VALUE ! ! ! FALSE !
! BOOLEAN ARRAY TRUTH .--!---!----->! FALSE !
! TEXT S .--!---!--- ! FALSE !
! REAL NUM 3.5 ! ! ! ! TRUE !
! ..... ! ! ! ! FALSE !
-->! CALL_BY_VALUE ! ! ! ---------
! ! ! ! !
! --------------------------- ! ! ---------
! ! --->! "+++" !
! --------------------------- ! ---------
! ! ! ! !
---!----. ! .------!---- ---------
! ! ! ----->! "+++" !
!-------------------------! ! ---------
! ! !
! REAL X 4.0 ! ! ---------
! REAL Y 3.5 ! ! -->! "O.K."!
! TEXT T1 .----!----- ! ---------
! TEXT T2 .----!--------
current ! BOOLEAN ARRAY B .----!--- ---------
-->! ..... ! ! ! FALSE !
statement ! ! ------->! FALSE !
--------------------------- ! TRUE !
! FALSE !
---------
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 107
CHAPTER 2.5.4
Call by reference
-----------------
A formal-parameter called by reference designates a local copy of the
reference obtained by evaluating the corresponding actual-parameter.
The evaluation takes place at the time of the procedure entry or
object generation. Throughout the lifespan of the PROCEDURE- or
CLASS-body, the formal-parameter acts like a local quantity.
If the formal-parameter is a reference-type variable, its contents may
be changed by assignments within the body (or externally by remote
accessing in the case of objects).
An ARRAY, PROCEDURE, LABEL or SWITCH parameter called by reference
remains fixed and references the same entity throughout its scope. Of
course, the contents of an ARRAY called by reference may well be
changed through assignments to its components.
For an object-reference type parameter (which may be a variable,
PROCEDURE or an ARRAY), the qualification of the matching
actual-parameter may coincide with, or be inner to, the qualification
of the formal-parameter.
SIMSET BEGIN INTEGER PROCEDURE NULLREF(L,N); REF(LINK) ARRAY L;
INTEGER N;
BEGIN INTEGER J, COUNT;
FOR J := 1 STEP 1 UNTIL N DO
IF L[J] == NONE THEN COUNT := COUNT + 1;
NULLREF := COUNT;
END;
INTEGER C;
REF(LINK) ARRAY Q[1:50];
......
C := NULLREF(Q,50);
......
END
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 108
CHAPTER 2.5.4
On the procedure call, a snapshot is
-----------------------
! ! !<-----
----------------------- !
! SIMSET ! !
----------------------- !
! PROCEDURE NULLREF ! !
! INTEGER C ! ! --------
! REF(LINK) ARRAY Q .-!-----!---->! .--!---->
! .......... ! ! -->--------
---->! C := NULLREF(1,50) ! ! ! ! .--!---->
! ! .......... ! ! ! --------
! ----------------------- ! ! ! NONE !
! ! ! --------
! ! ! ! NONE !
! ----------------------- ! ! --------
-----!----. ! .----!------ ! ! !
----------------------- ! !------!
! INTEGER NULLREF 0 ! ! ! !
! INTEGER N 50 ! ! --------
! REF(LINK) ARRAY L .-!--------- ! .---!---->
! ! --------
current ! .......... !
--->! !
statement -----------------------
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 109
CHAPTER 2.5.4
Call by name
------------
Call by name is an optional transmission mode available for parameters
to procedures, but not to classes. It represents a textual
replacement in that the formal-parameter may be considered replaced
throughout the PROCEDURE-body by the corresponding actual-parameter.
Whereas call by value and call by reference operate on variables local
to the PROCEDURE-body itself, call by name operates on non-local
quantities and can alter global quantities. It is therefore
especially useful for the controlled alteration of several variables
external to the PROCEDURE-body.
The following rules apply:
1) The type of a name parameter is that prescribed by the
corresponding formal specification.
2) If the type of the actual-parameter does not coincide with that of
the formal specification, then an evaluation of the expression is
followed by an assignment of the value or reference obtained to a
fictitious variable of the latter type. This assignment is
subject to the rules of section 2.7.2. The value or reference
obtained by the evaluation is the contents of the fictitious
variable.
Section 2.7.2 defines the meaning of an assignment to a variable which
is a formal-parameter called by name, or is a subscripted variable
whose array identifier is a formal-parameter called by name, if the
type of the actual parameter does not coincide with that of the formal
specification.
Assignment to a PROCEDURE-identifier which is a formal parameter is
illegal, regardless of its transmission mode.
Notice that each dynamic occurrence of a formal-parameter called by
name, regardless of its kind, may invoke the execution of a
non-trivial expression, e.g. if its actual-parameter is a
remote-identifier.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 110
CHAPTER 2.5.4
Example:
BEGIN PROCEDURE SWAP(A,B); NAME A, B; REAL A, B;
BEGIN REAL X;
X := A;
A := B; B := X;
END ***SWAP***;
REAL P, Q;
P := 4.0; Q := 5.7;
SWAP(P,Q);
..........
END
A snapshot at the procedure call is:
-------------------
! ! !<----
------------------- !
! PROCEDURE SWAP ! !
! REAL P 4.0 ! !
! REAL Q 5.7 ! !
! .......... ! !
--->! SWAP (P,Q) ! !
! ------------------- !
! ^ ^ !
! ! ! !
! ! ! !
! -----------!-!----- !
----!---. ! ! ! .--!-----
-----------!-!-----
! ! ! !
! REAL A . ! !
! REAL B . !
! REAL X 0.0 !
! ! Program Sequence Control
PSC --->! .......... ! (PSC) references the current
------------------- statement
No local copies are made. Every occurrence of A or B in the
PROCEDURE-body means a re-evaluation of the actual-parameter. Notice
that the actual-parameters are evaluated in the context of the
procedure call.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 111
CHAPTER 2.5.5
2.5.5 CLASS DECLARATIONS
CLASS declarations define concepts. CLASS instances are called
objects and many objects of a given class may exist simultaneously to
be examined and manipulated by the program. Objects are
generalizations of blocks and procedures, as the environment of either
a block instance or a procedure instance can only observe the result
of its actions.
CLASS-declaration
[CLASS-identifier]main-part
main-part
** **
* ; *
CLASS CLASS-identifier ** **
* parameter-part *
** **
[protection-part] [virtual-part] CLASS-body
parameter-part
(identifier-list); [VALUE identifier-list;]... CLASS-spec-part
CLASS-spec-part
** **
* ** ** *
* * [LONG]REAL * *
* * [SHORT]INTEGER * *
* * CHARACTER * *
** ** BOOLEAN ** identifier-list; ... **
* * REF(CLASS-identifier) * *
* * TEXT * *
* * [type]ARRAY * *
* ** ** *
** **
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 112
CHAPTER 2.5.5
protection-part
** **
* ** ** *
* * HIDDEN * *
* * PROTECTED * *
** [NOT] ** HIDDEN PROTECTED ** ** ...
* * PROTECTED HIDDEN * *
* ** ** *
** **
virtual-part
** **
* ** ** *
* * PROCEDURE * *
* * type PROCEDURE * *
virtual: ** ** label ** identifier-list; ... **
* * SWITCH * *
* ** ** *
** **
CLASS-body
** **
* statement *
** **
* split-body *
** **
split-body
BEGIN [declaration;] ... [statement;] ... INNER
[; statement] ... END
The available transmission modes for legal parameters to classes are
shown in the following table:
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 113
CHAPTER 2.5.5
CLASS PARAMETERS
Parameter Transmission
call by value call by reference
---------------------------------
value-type D X
reference-type X D
TEXT O D
value-type ARRAY O D
reference-type ARRAY X D
D : default mode
O : optional
X : illegal
The transmission modes "call by value" and "call by reference" are
explained in section 2.5.4.
The bounds of an array declared after the initial BEGIN of a
CLASS-declaration may be taken or computed from the parameters of the
CLASS.
The discussion of CLASS-declarations begins by considering two
selected examples of increasing scope.
Example 1: Empty prefix and virtual part
The declaration of a class A can have the form:
CLASS A(fpA); spA; ------------
! fpA !
BEGIN dA; ------------
! dA !
actionsA; ------------
! actionsA !
END ------------
CLASS A declaration A object
A: CLASS-identifier
fpA: List of the format parameters of A
spA: List of specifications of each of the formal
parameters of A.
dA: Declarations of the CLASS-body of A.
actionsA: actions of the CLASS-body of A
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 114
CHAPTER 2.5.5
The CLASS-body of A is a block (one form of statement).
The quantities passed as parameters or declared in the outermost block
of the class body are called the attributes of class A and are
attributes of every object of the class. Attributes specified as
formal-parameters may only be simple variables or arrays. Declared
attributes may be simple variables, arrays, proper-procedures,
function-procedures and classes.
The expression
NEW A(...)
creates an object of the class A (the order and number of the
actual-parameters must correspond with the order and number of the
formal-parameters) and commences execution of its actions. The
execution continues until the final END of the class body is
encountered, when the execution is terminated. However this may be
interrupted in four ways - by a GOTO-statement (which leads out of the
object), or by calls on the system procedures "detach", "resume" or
"call". A GOTO exit will leave the object in the terminated state.
"Detach" suspends the actions of the class body and names it an
independent component of the program. Its actions may be continued
later by a call on "resume".
An object is "attached" either under generation as a result of NEW or
when it is "call"-ed.
In many cases, it may be better to use CALL or RESUME on class objects
instead of using ordinary procedure calls. CALL or RESUME on CLASS
objects have the following advantages compared to procedure calls:
- No memory is allocated, which means that CALL or RESUME uses much
less CPU time than a procedure call.
- Data can be kept within the class object between CALLs or RESUMEs.
On the other hand, procedure calls can have parameters, but no
parameters can be transferred to the class when you make a CALL or
RESUME on a class object.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 115
CHAPTER 2.5.5
Initialization of CLASS attributes.
There are three ways to initialize CLASS attributes in SIMULA:
1) Attributes which are parameters to the CLASS are initialized by the
actual parameters in the NEW command.
2) Attributes can be initialized by executable statements before the
first "detach" in the CLASS. This can for example be used to include
each new CLASS object into a set immediately at creation, or to give
each new CLASS object a unique number.
3) If none of the above is done, the attribute is given a default
initial value, see chapter 2.5.1.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 116
CHAPTER 2.5.5
Example 2: Non-empty prefix and empty virtual part
A CLASS-declaration may contain a prefix which is the identifier of
another class declared either in the same block, or in the prefix to
the same block. The prefixed class is a subclass of the prefix.
e.g.,
------------
! FPA !
A CLASS B(fpB); spB; ------------
! DA !
BEGIN dB; ------------
! actionsA !
actionsB; ------------
! fpB !
END ------------
! DB !
------------
! actionsB !
------------
CLASS B declaration B object
A B-object is a compound object which has all the attributes and
actions of the prefix A and the main-part of class B. A B-object is
generated by
NEW B(apA, apB)
with a list of actual-parameters corresponding in number and order to
those of an A-object and those of the main-part of B. On generation,
the actions of the A-part are executed first and then those of the
B-part. The actions of the A-part have access to the attributes of A
only, the actions of the B-part to those of B and of A.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 117
CHAPTER 2.5.5
CLASS HIERARCHIES
-----------------
In general, a hierarchy of classes may be introduced.
e.g.
declarations
CLASS C1......;
C1 CLASS C2......;
C1 CLASS C3......;
C2 CLASS C4......;
C2 CLASS C5......;
hierarchy objects
--------- -------
C1 C2 C3 C4 C5
----C1---- ------ ------ ------ ------ ------
! ! ! C1 ! ! C1 ! ! C1 ! ! C1 ! ! C1 !
----C2---- C3 ------ ------ ------ ------ ------
! ! ! C2 ! ! C3 ! ! C2 ! ! C2 !
C4 C5 ------ ------ ------ ------
! C4 ! ! C5 !
------ ------
The prefix sequence of a class is the sequence of classes in its
prefix chain
e.g. in the above figure, the prefix sequence of
C1 is empty
C2 is C1
C5 is C1 C2
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 118
CHAPTER 2.5.5
If the prefix sequence of a class CN is C1, C2,....., CN-1, then a CN
object may be depicted by:
--------- **
! C1 ! *
--------- *
! C2 ! ** classes outer to CK
--------- *
! ..... ! *
** --------- **
* ! CK ! class equal to CK
subclasses of CK * --------- **
or classes ** ! ..... ! *
included in CK * --------- ** classes inner to CK
* ! CN ! *
** --------- **
An object of a prefixed class is a compound object which is the union
of the formal-parameters, declarations and actions of the classes in
its prefix sequence together with the structure defined in its own
main-part.
The mechanism of concatenation may be extended to the case of
prefixed-blocks, e.g.
SIMULATION BEGIN
...
END
The execution of a prefixed block begins by executing the actions of
the initial operations of the class and then those of the block body.
The attributes of the class are accessible inside the block body and
this block is thus given a built-in environment in which to operate.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 119
CHAPTER 2.5.5
INNER
-----
The order of the execution of actions in an object may be altered from
their textual order by use of INNER.
Consider
CLASS A ...;
BEGIN ....; S1; INNER; S2 END;
A CLASS B ...;
BEGIN .....; S3 END
In an A object INNER acts as a dummy statement, and the actions
executed are
S1; S2
In a B object, INNER forces execution of S3 before those of S2, thus
S1; S3; S2
VIRTUAL QUANTITIES (6)
------------------
The virtual mechanism is a method of extending the rules of
accessibility, whilst still retaining security. The virtual mechanism
is useful in two circumstances.
1) to redefine attributes
2) to give accessibility to attributes declared at inner levels
1) attribute redefinition
----------------------
Usually when a class hierarchy is constructed, an attribute has a
fixed meaning no matter how many prefix levels are added to the
class containing its declaration.
Sometimes, however, we may wish to redefine the attribute
throughout its scope.
---------------------------------------------------------------------
(6) This section may be bypassed by readers starting to learn SIMULA.
Though it concerns a very useful mechanism, it is not necessary to
learn initially. Most SIMULA programs do not use virtual quantities.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 120
CHAPTER 2.5.5
Example: Consider the description of a CLASS ROW for manipulating
vectors.
CLASS ROW(A,N); REAL ARRAY A; INTEGER N;
BEGIN REAL PROCEDURE NORM;
BEGIN REAL T; INTEGER I;
FOR I := 1 STEP 1 UNTIL N DO
T := T + A[I]*A[I];
NORM := SQRT(T);
END ***NORM***;
PROCEDURE NORMALISE;
BEGIN REAL T; INTEGER I;
T := NORM;
IF T NE 0 THEN
BEGIN T := 1/T;
FOR I := 1 STEP 1 UNTIL N DO
A[I] := A[I]*T;
END;
END ***NORMALISE***;
IF N < 1 THEN ERROR;
END ***ROW***
Note: Procedure attributes to classes can be used to get a function
equivalent to several entry points into subroutines as available in
other programming languages.
A new ROW object has four attributes:
1) a REAL ARRAY A running from 1 through N
2) a specified upper bound N
3) a REAL PROCEDURE NORM which computes the square root of the
sum of the square of its components. (NORM gives the
"magnitude" of the ARRAY A).
4) a PROCEDURE NORMALISE which divides through each array element
by the current value of NORM.
If the user wishes to use a different NORM then the class has to
be rewritten.
However by altering the class outline to
CLASS ROW(A,N); REAL ARRAY A; INTEGER N;
VIRTUAL : REAL PROCEDURE NORM;
BEGIN REAL PROCEDURE NORM...;
PROCEDURE NORMALISE...;
IF N < 1 THEN ERROR;
END ***ROW***
it becomes possible to alter the definition of NORM in a subclass
of ROW, and yet have the new meaning available at the ROW level
where it is needed in any call on NORMALISE e.g.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 121
CHAPTER 2.5.5
ROW CLASS ROW1;
BEGIN REAL PROCEDURE NORM;
BEGIN REAL S,T; INTEGER I;
FOR J := 1 STEP 1 UNTIL N DO
BEGIN T := ABS(A(I));
IF T > S THEN S := T;
END;
NORM := S;
END ***NORM*** ;
END ***ROW1***
ROW OBJECT ROW1 OBJECT
----------------------- -----------------------
! REAL ARRAY A ! ! REAL ARRAY A !
! INTEGER N ! ! INTEGER N !
! VIRTUAL : NORM .----!--- ! VIRTUAL : NORM .----!---
! REAL PROCEDURE NORM !<-! ! PROCEDURE NORMALISE ! !
! PROCEDURE NORMALISE ! ----------------------- !
----------------------- ! REAL PROCEDURE NORM !<--
-----------------------
IN A ROW1 object, the NORM attribute declared at the ROW level is
deleted and is never available. Though the VIRTUAL mechanism, the
only valid NORM attribute is that declared at the ROW1 level.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 122
CHAPTER 2.5.5
2) Inner accessibility
This is illustrated by an example.
In processing a linked structure which contains objects of various
classes, (say A, B) the links are provided by their common part
CLASS NODE.
CLASS NODE;BEGIN REF(NODE)NEXT; END;
NODE CLASS A; BEGIN PROCEDURE DUMP ....; END;
NODE CLASS B; BEGIN PROCEDURE DUMP ....; END;
If the structure is linked by following REF(NODE) NEXT references,
then, in the normal way, the information in the structure would be
dumped by
X :- FIRST;
WHILE X =/= NONE DO
BEGIN IF X IS A THEN X QUA A.DUMP
ELSE X QUA B.DUMP;
X :- X.NEXT;
END;
which is tedious to write. By writing the classes by
CLASS NODE; VIRTUAL : PROCEDURE DUMP;
BEGIN REF(NODE) NEXT;
...
END ***NODE*** ;
NODE CLASS A;
BEGIN PROCEDURE DUMP ...;
END;
NODE CLASS B;
BEGIN PROCEDURE DUMP ...;
END;
we can write instead
X :- FIRST;
WHILE X =/= NONE DO
BEGIN X.DUMP;
X :- X.NEXT;
END;
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 123
CHAPTER 2.5.5
A virtual quantity is either unmatched or else matched with an
attribute (with the same identifier) declared at the same or an
inner prefix level. The matching attribute must be of the same
type as that specified in the virtual part, except in the case of
object-reference-function-procedures. The type REF(C) may be
matched with the type REF(C) or type REF(D), where D is a subclass
of C. A VIRTUAL proper-PROCEDURE may be matched with any type of
procedure. In both these cases, the type of the match is the type
of the matching declaration.
A virtual quantity of a given object can have at most one matching
attribute. If matching declarations are given at more than one
prefix level, then the one at the innermost prefix level is taken.
The match is valid at all prefix levels of the object equal or
inner to that of the specification.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 124
CHAPTER 2.5.6
2.5.6 EXTERNAL DECLARATIONS
external-identifier
-------------------
** **
* ** ** *
identifier * = identifier * [ project number, programmer number ] * *
* ** ** *
** **
external-declaration
--------------------
** ** ** **
* ** ** * * *
* * type * PROCEDURE * * *
* ** ** * external- * external- *
EXTERNAL ** ** * , * ...
* CLASS * identifier * identifier *
* * * *
** ** ** **
The EXTERNAL declaration is used when a separately compiled procedure
or CLASS written in SIMULA, MACRO 10 or FORTRAN is to be used. In the
main program, the EXTERNAL declaration is put at the place where the
separately compiled segment would have been put if it had not been
separately compiled. In a separately compiled procedure or class, the
EXTERNAL declaration is put in front of the source code.
The external identifier gives the file name of the disk file on which
the separately compiled segment is stored. For FORTRAN and MACRO
procedures, the external identifier gives the filename of the dummy
SIMULA body for the procedure, often but not necessarily identical to
the filename of the FORTRAN or MACRO procedure itself.
More information about separate compilation is given in DECsystem-10
SIMULA Language Handbook Part I chapter 4 and in DECsystem-10 SIMULA
Language Handbook part II.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 125
CHAPTER 2.5.7
2.5.7 HIDDEN PROTECTED SPECIFICATIONS
[The HIDDEN PROTECTED specification is not available in release 1 and
2 of DECsystem-10 SIMULA, but available from release 3.]
The HIDDEN PROTECTED feature is a feature to increase the reliability
and security of large software packages by dividing the package into
smaller submodules and controlling the interface between the
submodules.
Many programming errors occur because a programmer, when writing code
in one submodule, is not aware of the effect of that code on other
submodules. If the interface between the modules is controlled, the
compiler and program can automatically guard against many such
programming errors.
This is especially important when several programmers are working on
the same project, or when one programmer is writing a program using
one or several packages developed previously by someone else.
The natural submodule in SIMULA is a CLASS. This CLASS is sometimes
separately compiled (See Chapter 4). However, programs using a
separately compiled CLASS do not ordinarily use directly all the
attributes of the separately compiled CLASS. Some attributes are
internal to the CLASS and only used by code inside the CLASS. Other
attributes are "ports of entry" to the CLASS. Often, these "ports of
entry" are PROCEDURE attributes to the CLASS, since PROCEDUREs can
include code to check the correctness of the input parameters before
performing the requested actions.
The simplest use of the HIDDEN PROTECTED specification is to declare
as HIDDEN PROTECTED those attributes which are not to be accessible
outside the body of the CLASS. Suppose for example that we have a
CLASS "data base" where the user of the CLASS need only access the
features of the CLASS through the attribute PROCEDUREs "put" and
"get". All other attributes of the CLASS are then declared HIDDEN
PROTECTED as in the following simplified excerpt:
CLASS data_base;
HIDDEN PROTECTED diskdata, has_been_read, filesize,
filepos, internal;
BEGIN
REF (directfile) diskdata;
BOOLEAN has_been_read;
INTEGER filesize, filepos;
PROCEDURE internal; COMMENT this PROCEDURE is only
used internally inside the class data_base;;
PROCEDURE PUT; COMMENT port accessible from
outside the CLASS ...;;
PROCEDURE GET; COMMENT port accessible from
outside the CLASS ...;;
COMMENT etc. ;
END of data_base;
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 126
CHAPTER 2.5.7
If most of the attributes of a CLASS are to be HIDDEN PROTECTED, and
only a few attributes are to be non-protected ports, then it is easier
to list the non-protected attributes. This can be done using the NOT
HIDDEN PROTECTED specification. The CLASS in the example above could
then instead begin:
CLASS database;
NOT HIDDEN PROTECTED put, get;
BEGIN ...
The NOT HIDDEN PROTECTED specification indicates that all attributes
which can be specified HIDDEN PROTECTED at that place in the program,
and which are not listed in the specification, are specified to be
HIDDEN PROTECTED.
The syntax of the HIDDEN PROTECTED specification is defined in section
2.5.5 above.
2.5.7.1 SEMANTICS OF THE HIDDEN PROTECTED SPECIFICATION
Attributes declared PROTECTED are only visible inside the body of the
class where they have been specified PROTECTED, and inside the body of
subclasses to this class and inside the body of blocks prefixed with
this class or a subclass to it.
Note that inside this body, the attributes are visible not only by
direct access but also by remote access (dot notation or INSPECT
statements) to other objects of the same CLASS. [NOTE! Accessing
local PROTECTED attributes remotely has not yet been confirmed by
SIMULA DEVELOPMENT GROUP.]
If an identifier in the source program, outside this scope, would
without PROTECTED refer to the PROTECTED variable, that identifier
will instead act as if the PROTECTED variable cannot be seen, it will
thus either refer to a statically enclosing identifier with the same
name, or it will give the compile time error message "UNDECLARED
IDENTIFIER".
Attributes declared HIDDEN are invisible in subclasses to the class
where the HIDDEN specification occurs and in blocks prefixed with this
class or subclasses to it.
The combined specification HIDDEN PROTECTED will thus make the
variables invisible everywhere except in the body of the class with
the HIDDEN PROTECTED specification.
A VIRTUAL attribute may only be specified PROTECTED in the same CLASS
heading where the VIRTUAL specification is placed. If a VIRTUAL
attribute is declared HIDDEN, the effect is that procedures with the
same name in subclasses will not take part in the virtual match. They
will instead act as ordinary (non-virtual) procedures.
Attributes of a class may only be specified PROTECTED in the heading
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 127
CHAPTER 2.5.7.1
of the class where the attribute is declared. Attributes of a class
may, however, be declared HIDDEN in a subclass to it. Such a HIDDEN
specification will only be valid for subclasses to the class where the
HIDDEN specification is placed.
An attribute may not be specified HIDDEN except when it is specified
PROTECTED in the same class or in a superclass.
If a HIDDEN specification contains an identifier which is ambiguous,
because the same identifier has been used for different attributes
within the prefix chain, then the HIDDEN specification will take
effect for all these attributes with the same name. [NOTE! This
mechanism may be changed in the future, depending on SIMULA
DEVELOPMENT GROUP decisions. The definition might be changed so that
each HIDDEN just nullifies one PROTECTED level at a time.]
All HIDDEN specifications at the start of a certain CLASS must either
be of the NOT kind or of the positive kind. Mixed specifications are
illegal. The same is true for the PROTECTED specifications. However,
HIDDEN and PROTECTED may be of different kind.
2.5.7.2 EXAMPLES OF USE OF THE HIDDEN PROTECTED SPECIFICATION
Example i: WRITE-PROTECTED ATTRIBUTES
The attributes "length", "width" and "height" of the following CLASS
can be given values when a new CLASS object is generated, but can
never be changed in an existing CLASS object.
The attribute "density" can only be changed through the procedure
"setdensity" which checks that the new value is within a legal range.
The attribute values can all be used outside the CLASS body, but not
redefined, since the externally accessible ports are all PROCEDUREs.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 128
CHAPTER 2.5.7.2
CLASS box (internal_length, internal_width,
internal_height, internal density);
REAL internal_length, internal_width,
internal_height, internal density;
NOT HIDDEN PROTECTED length, width, height, density, set_density;
BEGIN
REAL PROCEDURE length; length:= internal_length;
REAL PROCEDURE width; width:= internal_width;
REAL PROCEDURE height; height:= internal_height;
REAL PROCEDURE density; density:= internal_density;
PROCEDURE set_density(new_density);
IF new_density < 0 OR new_density > 10 THEN abort
ELSE internal_density:= new_density;
set_density(internal_density); COMMENT to check initial value;
...
END;
Example ii: SIMSET AS IN SIMULA COMMON BASE
CLASS simset;
BEGIN
CLASS linkage;
PROTECTED i_suc, i_pred;
BEGIN
REF (linkage) i_suc, i_pred;
END;
linkage CLASS link;
HIDDEN i_suc, i_pred;
BEGIN
PROCEDURE out;
BEGIN
IF i_suc =/= NONE THEN
BEGIN ....
END;
END;
END;
END;
As is seen above, the internal, HIDDEN attributes i_suc and i_pred are
invisible outside LINKAGE, except within the subclasses LINK (and
HEAD, analoguous to LINK) since they are declared PROTECTED in
LINKAGE, but declared HIDDEN in LINK (and HEAD).
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 129
CHAPTER 2.5.7.2
Example iii: INVISIBLE, NOT FORBIDDEN
This example shows that PROTECTED attributes are invisible rather than
forbidden:
BEGIN
INTEGER b;
CLASS a; HIDDEN PROTECTED b;
BEGIN INTEGER b;
END;
a CLASS asub;
BEGIN
b:= 3; COMMENT legal, but refers to the b outside a;
END;
INSPECT NEW a DO
BEGIN
b:= 1; COMMENT legal, but refers to the b outside a;
END;
a BEGIN
b:= 2; COMMENT legal, but refers to the b outside a;
END;
END;
Example iv: LABELS CAN ALSO BE HIDDEN
BEGIN
CLASS a;
HIDDEN PROTECTED la;
BEGIN
INNER;
la: lb:
END;
a CLASS b;
BEGIN
GOTO la; COMMENT illegal;
GOTO lb; COMMENT legal;
END;
END;
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 130
CHAPTER 2.5.7.2
Example v: PROTECTING THE NAME OF A CLASS.
BEGIN
CLASS a;
HIDDEN PROTECTED b;
BEGIN
REF (b) bl;
CLASS b;
BEGIN INTEGER i; END;
bl:- NEW b;
END of a;
INSPECT NEW a DO outint(bl.i); COMMENT legal;
END;
Class a has a local class B which is HIDDEN and PROTECTED. This
protects against all statements where the name of the local class
appears. Thus, the following is impossible outside the body of a:
> Creation of new objects of the class b using the NEW statement.
> Declaration of references to b.
> Use of the WHEN clause in the INSPECT statement.
Nevertheless, it is possible to access the attributes of the instance
of the class b referred to by the reference variable b1 in the class
a, since b1 is not HIDDEN PROTECTED.
Example vi: PROTECTING THE "NEW" COMMAND OF SIMULA.
BEGIN
CLASS c; HIDDEN PROTECTED b;
BEGIN BOOLEAN b;
CLASS d;
BEGIN IF b THEN abort; END;
COMMENT here, "NEW d" will not cause any error!!;
b:= TRUE;
END;
INSPECT NEW c DO NEW d; COMMENT causes error!!!;
END;
If you want to protect just the "NEW" command and nothing else, this
construct can be used. Note however that the construct in example v
causes compile time error, the construct in example vi causes run time
error.
Class c has a boolean attribute B which is used to indicate if the
statement part is executed. Such an attribute may be used to inhibit
instance generation of a local class through a programmed runtime
check like that on line 6. The "NEW d" phrase on line 12 will result
in a call on the "abort" procedure.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 131
CHAPTER 2.6
2.6 EXPRESSIONS
-----------
Expressions are rules for computing values. Expressions may occur on
the right hand sides of assignment statements, as actual parameters,
in FOR-statements, as array indices, etc.
expression
** **
* arithmetic-expression *
* condition *
* CHARACTER-expression *
** designational-expression **
* object-expression *
* TEXT-expression *
* TEXT-value *
** **
IF-clause
IF condition THEN
The constituents of expressions are operators and operands. The
operands are constants, variables or function designators. No two
operands may occur side by side - they must be separated by at least
one operator. A discussion of variables and function designators
precedes the discussion of expressions.
value-expression
** **
* arithmetic-expression *
** condition **
* CHARACTER-expression *
** **
reference-expression
** **
* object-expression *
** **
* TEXT-expression *
** **
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 132
CHAPTER 2.6.1
2.6.1 VARIABLES
The value of a variable may be used in expressions for forming values
and may be changed by assignments to that variable. The value of a
variable is the value of the last assignment to it, or its initial
value if no assignment has yet been made.
variable
** **
* simple-variable *
** subscripted-variable **
* remote-variable *
** **
simple-variable
identifier
simple-variable
** **
* identifier *
** ** (subscript-list)
* remote-variable *
** **
subscript-list
arithmetic-expression [, arithmetic-expression]...
remote-variable
** **
* simple-text-expression . *
** ** identifier
* simple-object-expression . *
** **
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 133
CHAPTER 2.6.1
Examples:
simple-variable: EPS
A15
A16_C
subscripted-variable: SON[2]
ELEMENT[I,J]
THIS SQUARE.LONG_SIDE[2]
remote-variable: ANNA.FATHER
APOSTLE(6).LEADER
C.P.X
LINE(2).SIDE(3)
A variable is a designation for a single value.
simple-variable
The type of the value of a particular simple variable is given in the
declaration for that variable.
remote-variable
An attribute of an object is identified by the following information:
1) a reference to the object
2) a class which includes that of the object
3) an attribute identifier defined in that class or any class
belonging to its prefix sequence.
Let X be a simple object expression qualified by class C, and A an
attribute identifier.
Then X.A is valid if X =/= NONE and class C has at least one attribute
identified by A. If there is only one attribute with identifier A
contained in class C or in its prefix chain, then it is designated by
X.A. If class C contains more than one attribute with identifier A,
then X.A designates the attribute with identifier A at the innermost
prefix level.
N.B. The main part of any class declaration can contain at most one
attribute with that identifier.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 134
CHAPTER 2.6.1
Example:
REF(C1) X1; REF(C2) X2; REF(C3) X3; REF(C4) X4;
CLASS C1(A); REAL A;
BEGIN .................... END;
C1 CLASS C2;
BEGIN TEXT A; ... END;
C2 CLASS C3;
BEGIN .................... END;
C3 CLASS C4;
BEGIN BOOLEAN A; ........ END;
X1 :- X2 :- X3 :- X4 :- NEW C4(6.0);
remote-variable type
--------------- ----
X1.A, X2 QUA C1.A,
X3 QUA C1.A, X4 QUA C1.A REAL
X1 QUA C2.A, X2.A,
X3 QUA C2.A, X4 QUA C2.A TEXT
X1 QUA C3.A, X2 QUA C3.A,
X3.A, X4 QUA C3.A TEXT
X1 QUA C4.A, X2 QUA C4.A,
X3 QUA C4.A, X4.A BOOLEAN
It is not possible to access either label or switch identifiers
remotely.
If class C or a class in its prefix chain contains a class attribute,
then accessing of any attribute in class C is only possible through a
connection statement.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 135
CHAPTER 2.6.1
Example:
CLASS C1; BEGIN REAL D; END;
C1 CLASS C2;
BEGIN CLASS F.....;
BOOLEAN Q;
END;
REF(C2)X;
Then X.F, X.Q, X.D
are all illegal attempts at remote accessing.
But it is legal to write
INSPECT X DO
BEGIN ...F...
...Q...
...D...
END
or, for the REAL attribute of C1, X QUA C1.D.
A simple-text-expression is itself a compound structure in the sense
that it has attributes accessible through the dot notation.
TEXT-value assignments may be made through the use of the
system-defined procedure SUB, STRIP and MAIN to sub-fields (T.SUB,
T.STRIP) and super-fields (T.MAIN) of the text object referenced by T.
e.g. T.SUB(1,24) := "CHANGE IN FIRST 24 CHARS"
T.MAIN.STRIP := NOTEXT
Subscripted variables
A subscripted variable is an array component. The type of a
subscripted variable is the type of the array. Each arithmetic
expression in the subscript list is called a subscript and the
complete list of subscripts is enclosed in parentheses ( ), or square
brackets [ ]. (Note: Square brackets are preferred for better
readability.) Each subscript acts as a variable of type INTEGER and
the evaluation of the subscript is understood to be equivalent to an
assignment to this fictitious variable.
A run time error will occur when any of the subscripts is outside the
declared bounds on that subscript of the array. This can, at the
programmers own risk, be removed with the compiler switch -A.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 136
CHAPTER 2.6.2
2.6.2 FUNCTION DESIGNATORS
A function designator denotes the value obtained by evaluating the
associated procedure body when supplied with the associated actual
parameter list (if any).
function-designator
** **
* identifier *
** ** [actual-parameter-list]
* remote-identifier *
** **
actual-parameter-list
(actual-parameter[, actual-parameter]...)
actual-parameter
** **
* expression *
* ARRAY-identifier *
** SWITCH-identifier **
* PROCEDURE-identifier *
* LABEL-identifier *
** **
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 137
CHAPTER 2.6.2
Examples:
ININT
INTEXT(20)
SIN(A+B)
H.FIRST
CURRENT.NEXTEV.SUC
POINT(5).MODULUS
Function-designators denote single arithmetic, BOOLEAN, TEXT or
CHARACTER values or object- or TEXT-references. These values are
obtained by applying a set of rules defined by the procedure
declaration to a set of actual parameters. The actual parameter list
must correspond in number and order to the formal parameter list in
the corresponding procedure declaration.
Certain identifiers, expressed as procedures, are pre-defined in the
SIMULA system. A list is given in Appendix B. Calls to standard
procedures conform to the syntax of calls to declared procedures and
are equivalent to normal procedure calls. (Note, however, that
standard procedures may not be passed as parameters.) The identifier
of a system defined procedure is not reserved, and may be declared to
have another meaning at any level. (This is not recommended practice
as it will obviously make the program more difficult to read and
understand). The identifier then assumes the new meaning throughout
the scope of the block in which it was declared.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 138
CHAPTER 2.6.3
2.6.3 ARITHMETIC EXPRESSIONS
An arithmetic expression is a rule for computing a number.
arithmetic-expression
** **
* simple-arithmetic-expression *
** IF-clause simple-arithmetic-expression **
* ELSE arithmetic-expression *
** **
simple-arithmetic-expression
[+!-] arithmetic-primary [arithmetic-operator arithmetic-
primary] ...
arithmetic-primary
** **
* arithmetic-constant *
* arithmetic-variable *
** arithmetic-funtion-designator **
* (arithmetic-expression) *
** **
arithmetic-operator
+ - * ** ^ / //
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 139
CHAPTER 2.6.3
Examples:
arithmetic-primary
15.7
16R1FA
X
SIN(23*P1/180)
(IF X>0 THEN X ELSE -X)
arithmetic-expression
X**2 + Y**2
X + A(J)**2
EXP(2 + (IF B THEN 3 ELSE 4))
IF X > 0 THEN 1 ELSE IF X < 0 THEN -1 ELSE 0
-3*(-5)
Examples of incorrect arithmetic expressions:
(A + B) C) left parenthesis missing
-3*-5 two operators together
(A + B) & - 0.5 & only allowed in constants
X + (IF Y < 0 THEN 2) ELSE alternative is missing
X + IF Y < 0 THEN 2 ELSE 3 the IF expression must be
enclosed in parentheses
The value of a simple-arithmetic-expression is the value obtained by
executing the arithmetic operations on the actual numeric values of
the primaries of the expression. The actual numeric value of 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 function-procedure when applied to the
current values of the procedure parameters in the expression. For
arithmetic-expressions enclosed in parenthesis, 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-expressions, which include IF- clauses,
a simple-arithmetic-expression is selected on the basis of the actual
values of the BOOLEAN conditions.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 140
CHAPTER 2.6.3
If the form of the arithmetic expression is
IF condition THEN simple-arithmetic-expression
ELSE arithmetic-expression
the selection of the appropriate value is made according to the rules:
1. The condition in the IF-clause is evaluated.
2. If the result of 1 is TRUE, then the value of the expression is
the value of the simple arithmetic expression following the
IF-clause. Otherwise it is the value of the arithmetic expression
following the ELSE.
e.g. IF X < 0 THEN 4 ELSE 17
if X < 0 then the value is 4
if X = 0 or X > 0 then the value is 17.
Arithmetic operators and types
------------------------------
Apart from the CONDITIONS of IF-clauses, the constituents of
arithmetic expressions are of types SHORT INTEGER, INTEGER, REAL or
LONG REAL.
The following hierarchy may be associated with these types.
type number type shortened notation
1 [SHORT] INTEGER I
2 REAL R
3 LONG REAL LR
The types are ranked according to their associated type number. Thus
LONG REAL is higher than INTEGER, INTEGER is lower than REAL.
The meanings of the basic operators are:
+ addition
- subtraction
* multiplication
^ or ** exponentiation
/ division
// integer division
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 141
CHAPTER 2.6.3
The types of arithmetic expressions are given by the following rules:
1) The operators + and - may be used as unary operators
+ operand
- operand
The type of the resulting expression is the type of the operand.
2) The type of the arithmetic expression
operand1 [+!-] operand2
is the higher of the types of operand1 and operand2. This is
displayed in the table:
type of operand1 type of operand2
I R LR
------------------
!
I ! I R LR
R ! R R LR
LR ! LR LR LR
3) / denotes division, and
operand1 / operand2
always results in an arithmetic expression of type REAL or LONG
REAL. If either of operand1 or operand2 are of type LONG REAL
then so is the resulting expression, otherwise it is of type REAL.
This is displayed in the table:
type of operand1 type of operand2
I R LR
----------------------
!
I ! R R LR
R ! R R LR
LR ! LR LR LR
A run time error will always result if the value of operand2 is
zero.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 142
CHAPTER 2.6.3
4) // denotes integer division. The operator is defined only between
two operands of type INTEGER and gives the INTEGER result
A // B = SIGN (A*B) * ENTIER (ABS(A/B))
If, in
operand1 // operand2
the types of operand1 and operand2 are not both INTEGER, then they
are rounded to type INTEGER and then the operation, as defined
above, is carried out.
Examples:
10 // 5 = 2
9 // 5 = 1
-9 // 5 = -1
9 //(-5) = -1
5) The operation
operand1**operand2 or operand1^operand2
denotes exponentiation, where operand1 is the base and operand2
the exponent.
e.g. 2**3 means 8 (=2*2*2)
2**(3**4) means 2 to the power
(3 to the 4th power)
2**3**4 means 2 cubed to the 4th power
The type is REAL unless one of operand1 or operand2 is of type
LONG REAL when it is LONG REAL. (This is a difference from
Algol 60 where the type is INTEGER if both operands are positive
INTEGERs. However, if operand1 and operand2 are positive integers
and the result is less than 134258569, the result retains full
integer precision. In the case where both operands are integer
constants and operand2 is 2, no type conversion is performed.)
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 143
CHAPTER 2.6.3
6) When the type of an arithmetic expression can not be determined at
compile-time, it is considered to be the highest possible type in
the hierarchy of the alternatives.
If in
IF X > 0 THEN P.R ELSE S
the result of an expression is of one arithmetic type and the
expression is assigned to a variable of another arithmetic type,
the result is converted to the appropriate type.
7) For mathematical functions(like SIN or TAN) the type of the
function is the same as the type of the argument. Some of these
mathematical functions are not provided for the LONG REAL type.
In that case, a warning message is given and the REAL function is
used instead. (See Appendix B.) Note that abs works according to
Algol definiton - i.e. abs is [LONG] REAL even if actual
parameter is INTEGER. This might be changed in the future for
compatibility reasons.)
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 144
CHAPTER 2.6.3
Arithmetic operator precedence
------------------------------
The evaluation of an arithmetic-expression can be considered as taking
place in a number of scans through the expression, each scan going
from left to right:
1) The values of the constants, variables and function designators
are evaluated.
2) Any subexpression between a left parenthesis and its matching
right parenthesis is evaluated (according to rules 2, 3, 4, 5) and
is used as a primary in subsequent calculations.
3) All exponentiations are evaluated.
4) All multiplications, divisions and integer divisions are
evaluated.
5) All additions and subtractions are evaluated.
The operator precedences may be summarized by
1. ( ) [ ]
2. ** ^
3. * / //
4. + -
Arithmetics of REAL and LONG REAL quantities
--------------------------------------------
Quantities of type REAL and LONG REAL are defined to a finite
accuracy. Thus any operation performed on such quantities is subject
to a possible deviation. The analysis of the possible consequences
should be carried out by a numerical analyst.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 145
CHAPTER 2.6.4
2.6.4 CONDITIONS
Conditions (or BOOLEAN-expressions) return the values TRUE or FALSE.
Their prime use is in conditional expressions and conditional
statements.
condition
---------
** **
* BOOLEAN-primary [BOOLEAN-operator BOOLEAN-primary]... *
** **
* IF-clause BOOLEAN-primary ELSE condition *
** **
BOOLEAN-primary
---------------
** **
* BOOLEAN-variable *
** ** * BOOLEAN-function-designator *
* NOT * * TRUE *
* \ * ** FALSE **
** ** * relation *
* (condition) *
** **
BOOLEAN-operator
----------------
** **
* *
** AND ! OR ! EQV ! IMP **
* *
** **
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 146
CHAPTER 2.6.4
relation
--------
** **
* ** ** *
* * = * *
* * > * *
* * >= * *
* simple-value-expression ** < ** simple-value-expression *
* * <= * *
* * \= * *
* ** ** *
* *
* *
* ** ** *
* * = = * *
** simple-reference-expression ** ** simple-reference-expression **
* * =/= * *
* ** ** *
* *
* *
* ** ** *
* * IS * *
* SIMPLE-REFERENCE-EXPRESSION ** ** CLASS-IDENTIFIER *
* * IN * *
* ** ** *
** **
Note the equivalent modes of writing:
\ or NOT
= EQ
\= NE
< LT
<= LE
> GT
>= GE
Examples:
TRUE
FATHER AND SON
X = 0 OR \ (Y > C)
NOT (X IN HEAD)
T == NOTEXT
FATHER =/= NONE
C = 'A'
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 147
CHAPTER 2.6.4
BOOLEAN OPERATORS
The meanings of the logical operators
NOT not
AND and
OR or
IMP implication
EQV equivalent
are given in the table:
P ! T T F F
!
Q ! T F T F
!
------------------------------------
!
NOT P ! F F T T IF P THEN FALSE ELSE TRUE
P AND Q ! T F F F IF P THEN Q ELSE FALSE
P OR Q ! T T T F IF P THEN TRUE ELSE Q
P IMP Q ! T F T T IF P THEN Q ELSE TRUE
P EQV Q ! T F F T IF P THEN Q ELSE NOT Q
Note that a Boolean expression is always evaluated completely. in
some cases it may be more effeicient or even necessary to use the
expanded form given by the table above.
For example:
WHILE T.MORE AND T.GETCHAR = ' ' DO;
may work more safely coded:
WHILE (IF T.MORE THEN T.GETCHAR = ' ' ELSE FALSE) DO;
Precedence of OPERATORS
-----------------------
The sequence of operations within one condition is from left to right
with the following additional rules:
first: arithmetic expressions (+, -, **, ^, /, //)
according to section 6.3
second: relations (<, <=, =, NE, \=, >, >=, ==, =/=, IS, IN)
third: NOT
fourth: AND
fifth: OR
sixth: IMP
seventh: EQV
The use of parentheses is interpreted as in section 6.3.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 148
CHAPTER 2.6.4
Relations
---------
1) IS, IN
The operators IS and IN test the class membership of a referenced
object:
X IS C is TRUE only if X is a reference to an object belonging
to the class C, otherwise the value is FALSE
X IN C is TRUE only if X is a reference to an object belonging
to either the class C or to a sub-class of C, otherwise
the value is FALSE.
Both X IN C and X IS C are FALSE if X == NONE.
2) Reference comparators (==, =/=)
These operators compare either two simple text references or two
simple object expressions. Two object (text) references X and Y
are identical if they refer to the same object (text value
instance) or if both are NONE (NOTEXT). In these cases, the
relation X == Y is TRUE. Otherwise it is FALSE.
The relation X =/= Y has the value of NOT (X == Y).
If X and Y are two text references, then X =/= Y and X = Y may
both be TRUE if X and Y refer to physically distinct character
sequences which are equal.
3) Value comparators (=, NE, \=, >, >=, <, <=)
The relations take the value TRUE if the corresponding relation is
satisfied for the actual values of the expressions involved,
otherwise FALSE.
Examples:
5 = 3 is FALSE
' ' = '+' is FALSE
X < 0 is FALSE if the current value of X is
positive or zero, otherwise it is
TRUE
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 149
CHAPTER 2.6.4
If the values of two arithmetic expressions are compared and they are
of different types, then the value lower down in the hierarchy is
converted to the type of the higher before comparison is made.
Character values may be compared with respect to the collating
sequence. A relation
X REL Y
where X and Y are character values, and REL is a relational operator
has the same truth value as
RANK(X) REL RANK(Y)
Example:
'+' < '=' is TRUE RANK('+') = 43
RANK('=') = 61
Two text values are equal if they are both empty or if they are both
instances of the same character sequence. Otherwise they are unequal,
and then a text value T ranks lower than a text value U if one of the
following conditions is fulfilled:
1) T is empty
2) U is equal to T followed by one or more characters
3) If the first i-1 characters of T and U are the same, and the ith
character of T ranks lower than the ith character of U.
Examples:
NOTEXT = "" TRUE
"0" < "9" TRUE
"ABCDE"="ABCDEF" FALSE
"+12" NE "=12" TRUE
"ABC" = "ABCD" FALSE
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 150
CHAPTER 2.6.5
2.6.5 CHARACTER EXPRESSIONS
CHARACTER-expression
simple-character-expression
IF-clause simple-character-expression
ELSE character-expression
simple-character-expression
CHARACTER-constant
CHARACTER-variable
CHARACTER-function-designator
(CHARACTER-expression)
CHARACTER-constant
'(any character from the data character set)'
Example:
'''
'A'
IF X < 0 THEN ' ' ELSE 'Y'
The set of internal characters is ordered according to the collating
sequence (Appendix A). The collating sequence defines a one-one
mapping between internal characters and integers expressed by the
function procedures:
INTEGER PROCEDURE RANK (C); CHARACTER C;
whose value is in the range 0 through 127 and
CHARACTER PROCEDURE CHAR (N); INTEGER N;
The parameter value must be in the range 0 through 127 otherwise a run
time error results.
Two character subsets are defined by the standard procedures
BOOLEAN PROCEDURE DIGIT (C); CHARACTER C;
which is TRUE only if C is a digit, and
BOOLEAN PROCEDURE LETTER (C); CHARACTER C;
which is TRUE only if C is an upper or lower case letter.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 151
CHAPTER 2.6.5
Example:
The following program scans an input file on SYSIN until "end of file"
is met and records the number of occurrences of the digits 0 - 9.
BEGIN INTEGER ARRAY INCIDENCES [RANK('0') : RANK('9')];
CHARACTER C; INTEGER R;
WHILE NOT LASTITEM DO
BEGIN C := INCHAR;
IF DIGIT (C) THEN
BEGIN R := RANK(C);
INCIDENCES[R] := INCIDENCES[R] + 1;
END;
END;
...
END
2.6.6 DESIGNATIONAL EXPRESSIONS
A designational expression is a rule for obtaining the label of a
statement.
designational-expression
simple-designational-expression
IF-clause simple-designational-expression
ELSE designational-expression
simple-designational-expression
LABEL-identifier
SWITCH-identifier [subscript]
(designational-expression)
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 152
CHAPTER 2.6.6
Examples:
valid LAB
CHOOSE [I]
SELECT [IF X < 0 THEN 2 ELSE 3]
IF B < 0 THEN LAB_1 ELSE SLAB[1]
invalid X.LAB remote SWITCH- or LABEL-
identifiers are not allowed
The principle of evaluation is analogous to that of
arithmetic-expressions. In the general case, the conditions in the
IF-clauses will select a simple-designational-expression. If this is
a label the desired result is found. A switch designator, on the
other hand, refers to the corresponding switch declaration and by use
of the actual numerical value of its subscript (an
arithmetic-expression) selects one of the designational-expressions
listed in the switch declaration by counting from left to right.
Since this value itself may be a switch designator, the definition is
recursive.
The evaluation of the subscript is analogous to that of subscripted
variables.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 153
CHAPTER 2.6.7
2.6.7 OBJECT EXPRESSIONS
An object-expression is a rule for computing a reference to an object
or NONE. The type of the expression is REF (qualification).
object-expression
simple-object-expression
IF-clause simple-object-expression
ELSE object-expression
simple-object-expression
NONE
variable
function-designator
NEW CLASS-identifier[actual-parameter-part]
THIS CLASS-identifier
simple-object-expression QUA CLASS-identifier
(object-expression)
Examples:
X
X.Y
SIDE (3)
THIS HEAD.SUC
NEW INFILE("CARDS")
THIS LINK QUA SUBCLASS.ATTRIB
IF SUC IN LINK THEN SUC ELSE NONE
IF X =/= NONE
THEN (IF X.F =/= NONE THEN X.F.F ELSE NONE)
ELSE NONE
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 154
CHAPTER 2.6.7
Qualification
The qualification of an object-expression is defined by the following
rules:
1) The expression NONE is qualified by a fictitious class which is
inner to all declared classes.
2) A variable, array or function designator is qualified as stated in
the declaration (or specification, see below) of the variable or
array or procedure in question.
3) An object-generator, local-object or qualified-object is qualified
by the class of the identifier following the symbol NEW, THIS or
QUA respectively.
4) A conditional object-expression is qualified by the class at the
innermost prefix level which includes the qualification of both
alternatives. If there is no such class, the expression is
illegal.
In
IF B THEN NONE ELSE S
the qualification is that of S (by rule 1).
5) A formal parameter of object-reference type is qualified according
to its specification regardless of the qualification of the
corresponding actual parameter.
6) The qualification of a function-designator whose procedure
identifier is that of a virtual quantity, depends on the access
level. The qualification is that of the matching declaration, if
any, occurring at the highest prefix level equal to or less than
the access level, or if none, that of the virtual specification.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 155
CHAPTER 2.6.7
Object generators (NEW A....)
An object-generator invokes the generation and execution of an object
belonging to the identified class. The object is a new instance of
the corresponding (concatenated) class body. The evaluation of an
object generator consists of the following actions.
1) The object is generated and the actual parameters of the object
generator are evaluated. The parameter values and/or references
are transmitted. (For parameter transmission modes, see section
5.4).
2) Control enters the body of the object through its initial BEGIN
whereby it becomes operating in the "attached" state.
The evaluation of the object generator is completed:
Case a: Whenever the basic procedure "detach" is executed "on
behalf of" the generated object (see CHAPTER 3, section 1) or
Case b: upon exit through the final end of the object.
The value of an object-generator is the object generated as the result
of its evaluation. The state of the object after the evaluation is
either "detached" (case a) or "terminated" (case b).
In the SIMULA language, no command is available to explicitly remove
or destroy a class instance. This is instead done by a so-called
garbage collector, which automatically will remove those class
instances which are not accessible from a program.
Example I: If the only way to access a certain class object is the
reference variable A, then changing the value of A will cause removal
of the object (e.g. "A:- NONE").
Example II: If the only way to access a certain class object is
through its membership in a set, then the set operator "out" will make
it inaccessible and thus remove it. If the only way for the program
to reach members of a set or other data structure is through one
reference, e.g. a reference to the head of the set, then assigning a
new value to this reference will remove the entire set.
Qualification in connection with reference-assignment
Consider the object-reference-assignment
V:- object-expression
Both the left part and the right part have a qualification. Let these
be Ql and Qr respectively - note that NONE is here considered as
having a universal qualification which is inner to every other
qualification. The situations that can arise are illustrated in the
context:
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 156
CHAPTER 2.6.7
REF(CHAIN)C; CLASS CHAIN.............;
REF(MEMBER)M; CLASS MEMBER............;
REF(POINT)P: MEMBER CLASS POINT......;
REF(LINE)L; MEMBER CLASS LINE.......;
CASE 1: Ql is equal or outer to Qr
E.G.
A) M:-NEW MEMBER;
B) M:-NEW POINT......;
C) M:-P;
D) M:-NONE;
The assignment is legal. In B), the attributes of the
referenced POINT-object may be accessed by use of QUA as in
M QUA POINT.X
or by use of INSPECT as in
INSPECT M QUA POINT DO ... X ...
INSPECT M WHEN POINT DO ... X ...
Note the difference - in the first line a qualification error
will occur if M denotes a LINE or is NONE, in the second line
nothing will happen. See section 2.7.2 Connection
statements.
Case 2: Ql is inner to Qr
e.g.
A) P:-NEW MEMBER;
B) P:-M;
The assignment may be legal. A) is clearly not, but B) is
legal if M is currently referencing a POINT object or an
object of a class inner to POINT, e.g. after
M:-NEW POINT...;
This must be checked at runtime.
In cases 1 and 2, the qualifications Ql and Qr are said to be
compatible. Notice that compatibility is decided at compile time.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 157
CHAPTER 2.6.7
Case 3: Ql and Qr are not compatible.
e.g.
A) P:-NEW LINE.....;
B) P:-NEW CHAIN;
C) M:-C;
The assignment is illegal.
Similar rules apply to the object-reference assignments implicit in
the passing of parameters (FP:- AP) and assignments to the result
variable in a function procedure body.
Multiple assignments take the form
v1:- v2:- ... :- vn:- object-expression
and are equivalent to
vn:- object-expression
vn-1:- vn;
...
v1:- v2;
The considerations above apply at each step.
The fact that an object-reference-assignment is always checked for
legality (mainly at compile time) has the following implication. For
any object-reference-variable or indeed, object-expression whose value
is V and with qualification Qv, the following is always true under
program execution:
(V == NONE) OR (V IN Qv)
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 158
CHAPTER 2.6.7
Local objects
-------------
A local-object "THIS C" is a meaningful expression within
1) the class body of C or that of any subclass of C, or
2) a connection block whose qualification is C or a subclass of C.
The value of a local-object in a given context is the object which is,
or is connected by, the smallest textually enclosing block instance,
in which the local object is a meaningful expression. If there is no
such block, the local object is illegal. For an instance of a
PROCEDURE- or CLASS-body, "textually enclosing" means containing its
declaration.
Instantaneous qualification
---------------------------
Let X represent any simple reference expression, and let C and D be
class identifiers such that D is the qualification of X. The
qualified object "X QUA C" is then a legal object expression, provided
that C includes D or is a subclass of D. Otherwise, i.e., if C and D
belong to disjoint prefix sequences, the qualified object is illegal.
The evaluation of X QUA C at run time gives an error if the value of X
is NONE, or an object belonging to a class not included in C.
Otherwise the value of X QUA C is that of X. (Note the qualification
of X is D, whilst that of X QUA C is C).
2.6.8 TEXT EXPRESSIONS AND TEXT VALUES
A TEXT-expression is a rule for computing a reference to a TEXT
object. A TEXT-value is a rule for computing the value of a text
(i.e., string of characters).
TEXT-expression
---------------
** **
* simple-text-expression *
** **
* IF-clause simple-text-expression ELSE TEXT-expression *
** **
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 159
CHAPTER 2.6.8
simple-text-expression
----------------------
****************************
* NOTEXT *
* TEXT-variable *
* TEXT-function-designator *
* (TEXT-expression) *
****************************
TEXT-value
----------
**************************
* simple-text-expression *
* text-constant *
**************************
Examples:
--------
valid
-----
TEXT-expression NOTEXT
IF T.LENGTH < 5 THEN NOTEXT ELSE BLANKS(80)
(RUNE.T)
T.SUB(1,12)
TEXT-value "ANOTHER CONSTANT"
NOTEXT
"" (same as NOTEXT)
invalid
-------
IF T.LENGTH < 5 THEN "MAX FOUR"
ELSE "MIN FIVE"
TEXT-constants may not be constituents of
conditional expressions.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 160
CHAPTER 2.7
2.7 BLOCKS AND STATEMENTS
---------------------
A program is structured into blocks. A block consists of a block head
which defines properties of the block, and a compound tail which
defines the actions of the block. A block may be prefixed which means
that the block is built into a predefined environment.
There is no way for a block environment to interact with an inner
block (i.e., examine its current state). The environment can only
observe the result of its actions. A block may only be entered
through its initial BEGIN and attempts to do so by GOTO statements are
thus illegal.
2.7.1 BLOCKS AND COMPOUND STATEMENTS
program
-------
block ! compount-statement
block
-----
prefixed-block ! main-block
prefixed-block
--------------
** ** main-block
CLASS-identifier ** [actual-parameter-list] **
** ****compound-statement
main-block
----------
BEGIN [declaration;]...[statement;]... [statement]END
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 161
CHAPTER 2.7.1
compound-statement
------------------
BEGIN [statement;]...[statement]END
A block automatically introduces a new level of nomenclature. Any
identifier may be declared or appear as a label in the block and is
then said to be local to it. An entity represented inside a block has
no existence outside it and any entity represented by this identifier
outside the block cannot be directly accessed by use of it (see the
explanation of the binding rule in section 2.3).
When a block is prefixed, the identifiers declared in the
corresponding CLASS are made available. Nevertheless, an identifier
in the CLASS may be redefined in the main-block or compound-statement.
The execution of a block is as follows:
step 1: if the block is prefixed then the actual parameters (if any)
are evaluated.
2: if the declarations of the block contain array bounds then
these are evaluated. (They may make reference to parameters
of the prefix).
3: Execution of the statements body begins with the first
statement of the prefix, if any, otherwise with the first
statement of the main block. After execution of the block
body (unless it is a GOTO statement) a block exit occurs and
the statement textually following the entire block is
executed.
A CLASS identifier possibly followed by an actual parameter list can
prefix a main-block or compound-statement. This results in
concatenating the object of the stated class with that main-block or
compound-statement, which means that the capabilities of the stated
class and its including classes are available within that main-block
or compound statement.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 162
CHAPTER 2.7.1
When an instance of a prefixed block is generated, the formal
parameters of the class are initialised as indicated by the actual
parameters of the block prefix. A virtual quantity is identified by
the quantity defined by a matching declaration in the block head of
the main-block or compound-statement, or by the matching definition at
the innermost prefix level of the prefix sequence. The operation rule
of the concatenated object is defined by principles similar to those
given in section 5.5.
A prefixed-block plays a particular role in the quasi-parallel
sequencing of SIMULA: it defines a quasi-parallel system, a system
whose components have interactions independent from the program
outside the prefixed block, see CHAPTER 3.
The following restrictions must be observed when prefixing blocks:
An object in which reference is made to the object itself through use
of THIS is an illegal block prefix.
The CLASS-identifier of a prefix must refer to a class local to the
smallest block enclosing the prefixed block. If that CLASS-identifier
is that of a system class, it refers to a fictitious declaration of
that system class occurring in the block head of the smallest
enclosing block.
A compound-statement is a means of grouping several statements
together to act as one unit, as in
FOR I := 1 STEP 1 UNTIL 10 DO
BEGIN SUM := SUM + A[I];
SUMSQ := SUMSQ + A[I]^2;
END
where the controlled-statement is a compound-statement,
or of legalising a statement structure
IF X > 0 THEN BEGIN IF Y > 0 THEN QUADRANT := 1;
END
The structure is illegal without the BEGIN - END pair.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 163
CHAPTER 2.7.2
2.7.2 STATEMENTS
A statement is a unit of action in a program. Sequences of statements
may be grouped together to form compound statements or blocks.
Special notice must be taken of conditional statements which
effectively prevent a certain ambiguity from arising. For consider
IF condition1 THEN IF condition2 THEN S2 ELSE S3
which has two interpretations
1) IF condition1 THEN IF condition2 THEN S2 ELSE S3
-----------------------------
2) IF condition1 THEN IF condition2 THEN S2 ELSE S3
---------------------
This ambiguity is resolved by not allowing a conditional statement to
follow the THEN symbol. Now the two meanings are resolved by writing.
1) IF condition1 THEN
BEGIN IF condition2 THEN S2 ELSE S3 END
2) IF condition1 THEN BEGIN IF condition2 THEN S2 END
ELSE S3
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 164
CHAPTER 2.7.2
The same sort of ambiguity can arise with a WHILE-statement, a
FOR-statement, or a connection statement following a THEN.
IF condition1 THEN
WHILE J < 10 DO
IF condition2 THEN S1 ELSE S2
IF condition3 THEN
INSPECT X DO
IF condition4 THEN S3 ELSE S4
Here the syntax forces the ELSE-branch to belong to the nearest THEN,
but means that whereas we can write:
** **
* WHILE-statement *
IF condition THEN ** FOR-statement **
* connection-statement *
** **
we can not write
** **
* WHILE-statement *
IF condition THEN ** FOR-statement ** ELSE S
* connection statement *
** **
In this case, BEGIN - END are necessary round the WHILE-, FOR-, or
connection-statement.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 165
CHAPTER 2.7.2
OPEN AND CLOSED STATEMENTS
--------------------------
statement
---------
** **
* *
* open *
** closed **
* IF-statement *
* *
** **
open
----
** **
* *
* FOR-statement *
[label:].. ** WHILE-statement **
* connection-statement *
* *
** **
closed
------
** **
* *
* block *
* compound-statement *
* activation-statement *
* PROCEDURE-statement *
[label:].. ** dummy-statement **
* GOTO-statement *
* assignment-statement *
* object-generator *
* *
** **
label
-----
LABEL-identifier
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 166
CHAPTER 2.7.2
ASSIGNMENTS
-----------
Assignment-statements assign the value of an expression to one or
several variables or procedure identifiers. Assignment to a procedure
identifier may occur only within the body of the function procedure
defining the value of that function. The process of assignment takes
place in three steps:
1) any subscript expressions in the left variables are evaluated in
sequence from left to right
2) the expression is evaluated
3) the value of the expression is assigned to the left part variables
from right to left (see example below under Types).
assignment-state
----------------
** **
* *
* value-assignment *
** TEXT-value-assignment **
* reference-assignment *
* *
** **
value-assignment
----------------
** **
* *
* variable := * ... VALUE-expression
* PROCEDURE-identifier := *
* *
** **
Examples:
---------
X := 3.45;
C := D[I] := '+';
P.X := R.X + S.X;
Y := IF X > 0 THEN X ELSE -X;
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 167
CHAPTER 2.7.2
TEXT-value-assignment
---------------------
** **
* *
* variable:= *
* PROCEDURE-identifier:= *
** function-designator:= ** ...TEXT-value
* (IF-expression):= *
* *
** **
Examples:
---------
T:="MESSAGE";
T.SUB(1,5):=S:="12345";
(IF BOL THEN T1 ELSE T2):= "EOF";
Consider the TEXT-value-assignment
R := T;
let the length of R be Lr and the length of T be Lt. The
assignment is legal if Lr >= Lt, otherwise a run time error
results.
Lr = Lt The text value of T is copied into R
Lr > Lt The text value of T is copied into R left justified
and the remaining Lr-Lt positions are filled with blanks
Assignments to overlapping texts are unpredictable.
e.g., with
T.SUB(10,10) := T.SUB(15,10);
or T.SUB(15,10) := T.SUB(10,10);
The value assignment
T := NOTEXT;
is an efficient way of setting the value of T to blanks.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 168
CHAPTER 2.7.2
reference-assignment
--------------------
** **
* *
* variable:- *
** PROCEDURE-identifier:- ** ...reference-expression
* *
** **
Examples:
---------
T:-S:-U;
T:-BLANKS(10);
T:-NOTEXT;
T:-T.STRIP;
X:-Y:-Z;
X:-NEW CL;
X:-NONE;
X:-MEMBER.SUC;
NOTE
In case of type REF the runtime
qualification of the righthandside of
the assignment must be identical with or
a subclass to the qualification of the
lefthandside (see section 2.6.7).
The qualification CLASS on both sides of
the assignment statement must be
declared in the same instance of the
same block (e.g. CLASS body or PROCEDURE
body).
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 169
CHAPTER 2.7.2
Types
-----
The type of the expression and all the left part variables or
PROCEDURE-identifiers must be identical except in the case of
arithmetic assignments. In this case, the assignment
v1 := v2 := ...... vn := expression
is equivalent to
vn := expression
vn-1 := vn
.....
v1 := v2
So that if X is REAL and I INTEGER,
X := I := 3.57;
is equivalent to
I := 4;
X := 4.0;
and
I := X := 3.57;
is equivalent to
X := 3.57;
I := 4;
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 170
CHAPTER 2.7.2
GOTO-STATEMENTS
---------------
A GOTO statement interrupts the normal sequence of operations. The
value of a designational expression indicates the value of the label
of the next statement to be executed.
GOTO-statement
--------------
GOTO designational-expression
Examples:
---------
GOTO L
GOTO S[4]
GOTO S[IF N=0 THEN 2 ELSE 6]
GOTO IF N=0 THEN L1 ELSE L2
A GOTO statement may not lead into
a connection statement
a block which is not already active
a FOR-statement
A GOTO statement leaving an attached object leaves the object in the
terminated state.
When the value of a designational expression is a switch with an
undefined value (the index is out of range), the GOTO statement is
equivalent to the dummy statement
e.g.,
;GOTO S[-1]; is equivalent to
; ;
The effect of
;GOTO S[IP]; assuming IP is an INTEGER PROCEDURE
returning an undefined value is
equivalent to ;IP;
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 171
CHAPTER 2.7.2
Example:
-------
The program below prints out the first three verses of "The Twelve
Days of Christmas". The program logic is built around a SWITCH.
BEGIN SWITCH CASE := LINE1, LINE2, LINE3;
INTEGER VERSE;
TEXT ARRAY T[1:3];
T[1] :- COPY ("FIRST");
T[2] :- COPY("SECOND");
T[3] :- COPY("THIRD");
WHILE VERSE <= 3 DO
BEGIN
VERSE := VERSE + 1;
OUTTEXT("ON THE"); OUTTEXT(T(VERSE));
OUTTEXT("DAY OF CHRISTMAS"); OUTIMAGE;
OUTTEXT("MY TRUE LOVE SENT TO ME"); OUTIMAGE;
GOTO CASE[VERSE];
LINE3: OUTTEXT("THREE FRENCH HENS");
LINE2: OUTTEXT("TWO TURTLE DOVES, AND");
LINE1: OUTTEXT("A PARTRIDGE IN A PEAR TREE");
EJECT(LINE + 2);
END OF LOOP -
NOTE THAT A FOR-LOOP WOULD HAVE MADE THE LABELS INVISIBLE;
END
OUTPUT:
ON THE FIRST DAY OF CHRISTMAS
MY TRUE LOVE SENT TO ME
A PARTRIDGE IN A PEAR TREE
ON THE SECOND DAY OF CHRISTMAS
MY TRUE LOVE SENT TO ME
TWO TURTLE DOVES, AND
A PARTRIDGE IN A PEAR TREE
ON THE THIRD DAY OF CHRISTMAS
MY TRUE LOVE SENT TO ME
THREE FRENCH HENS
TWO TURTLE DOVES, AND
A PARTRIDGE IN A PEAR TREE
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 172
CHAPTER 2.7.2
DUMMY STATEMENTS
A dummy-statement executes no actions. It is a fictive statement
which serves syntactical explanations. In this way it is possible to
set several semicolons after each other and to place a label before
END.
dummy-statement
---------------
Examples:
---------
IF X > 0 THEN ELSE X := -X; (Note dummy THEN-branch)
BEGIN ...... LAB : END;
dummy-statement and external procedures
---------------------------------------
A dummy-statement is used instead of the body for a separately
compiled procedure which is actually written in another language than
SIMULA.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 173
CHAPTER 2.7.2
WHILE STATEMENTS
The WHILE-statement is used when a statement is to be repeatedly
executed as long as a condition is TRUE.
WHILE-statement
---------------
WHILE condition DO statement
Examples:
---------
WHILE NOT LASTITEM DO
BEGIN X := ININT;
COUNT := COUNT + 1;
SUM := SUM + X;
END;
X:-SET.FIRST;
WHILE X =/= NONE DO
BEGIN IF X IN POINT THEN NOP := NOP + 1 ELSE
IF X IN LINE THEN NOL := NOL + 1 ELSE
ERROR("FALSE ENTRY");
X :- X.SUC;
END;
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 174
CHAPTER 2.7.2
ACTIVATION STATEMENTS
---------------------
Activation statements are only valid inside a SIMULATION block. They
are fully described in Chapter 3, section 3.
FOR STATEMENTS
FOR-statements are control statements which cause controlled-
statements to be executed zero or more times.
There are three basic types of FOR statement element.
1) the controlled-statement is executed for a list of values (usually
irregular).
FOR I := 2, 13, 17 DO controlled-statement
2) the controlled-statement is executed a known number of times
FOR I := 1 STEP 1 UNTIL 10 DO
X[I] := I*I;
3) the controlled-statement is executed until a condition is met
FOR X :- X.SUC WHILE X =/= NONE DO
X QUA A.DUMP;
To increase the generality of the concept, these elements
themselves are allowed to form a list
FOR I := 1, 2, 4 STEP 1 UNTIL 10, I*I WHILE I > 200 DO
controlled statement
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 175
CHAPTER 2.7.2
FOR-statement
-------------
[label:]... FOR controlled-variable for-right-part DO
controlled statement
for-right-part
--------------
** **
* *
* := value-element [,value-element] *
** :- object-element [,object-element] **
* *
** **
value-element
-------------
** **
* *
* value-expression *
* arithmetic-expression STEP arithmetic-expression *
** UNTIL arithmetic-expression **
* value-expression WHILE condition *
* *
** **
object-element
--------------
** **
* *
* object-expression *
** object-expression WHILE condition **
* *
** **
Each execution of the controlled statement is preceded by an
assignment to the controlled-variable. Assignments may change the
value of this controlled variable during execution of the
controlled-statement.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 176
CHAPTER 2.7.2
for list elements
-----------------
The for list elements are considered in the order in which they are
written. When one for list element is exhausted, control proceeds to
the next, until the last for list element in the list has been
exhausted. Execution then continues after the controlled statement.
The effect of each type of for list element is defined below using the
following notation:
C: controlled variable
V: value expression
O: object expression
A: arithmetic expression
B: Boolean expression
S: controlled statement
The effect of the occurrence of expressions in for list elements may
be established by textual replacement in the definitions.
Alpha, beta, gama are different identifiers which are not used
elsewhere in the program. O identifies a non-local simple variable of
the same type as A2.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 177
CHAPTER 2.7.2
1. V
C := V;
S;
next for list element
2. A1 STEP A2 UNTIL A3
C := A1;
sigma := A2;
a : IF sigma*(C-A3) > 0 THEN GOTO beta;
S;
sigma := A2;
C := C + sigma;
GOTO alpha;
beta : next for list element
3. V WHILE B
alpha : C := V;
IF NOT B THEN GOTO beta;
S;
GOTO alpha;
Beta : next for list element
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 178
CHAPTER 2.7.2
4. O
C :- O;
S;
next for list element
5. O WHILE B
alpha : C :- O;
IF NOT B THEN GOTO beta;
S;
GOTO alpha;
beta : next for list element
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 179
CHAPTER 2.7.2
The controlled variable
-----------------------
The controlled-variable is a simple-variable which is not a
formal-parameter called by name, a PROCEDURE-identifier, a
remote-identifier nor a TEXT-identifier.
To be valid, all for list elements in a for statement must be
semantically and syntactically valid.
In particular each implied assignment is subject to the rules of
section 7.2.1.3.
The value of the controlled variable upon exit
----------------------------------------------
Upon exit from the for statement, the controlled variable will have
the value given to it by the last (explicit or implicit) assignment
operation.
Labels local to the controlled statement
----------------------------------------
The controlled statement in a FOR-loop always acts as if it were a
block. Hence, labels on or defined within such loops may not be
accessed outside the controlled statement.
Thus it is illegal to write:
GO TO LAB;
FOR I:= 1,2,3 DO
BEGIN LAB: ... END;
but legal to write:
GO TO START;
WHILE ..... DO
BEGIN
....
START:
...
END OF LOOP;
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 180
CHAPTER 2.7.2
PROCEDURE STATEMENTS
--------------------
A procedure-statement calls for the execution of the PROCEDURE-body.
Before execution, the formal-parameters of the procedure are replaced
by the actual-parameters.
PROCEDURE-statement
-------------------
[simple-object-expression.] PROCEDURE-identifier [(expression
[, expression]...)]
Examples:
---------
INTO(H)
OUTTEXT("***0***")
SYSIN.INIMAGE
The procedure statement must have the same number of actual parameters
in the same order as the formal-parameters of the procedure heading.
Restrictions
------------
1) An actual-parameter corresponding to a formal-parameter called by
NAME which is assigned to within the PROCEDURE-body must be a
variable.
2) If the formal-parameter is an ARRAY (PROCEDURE), then the number
of dimensions (actual-parameters) used within the PROCEDURE-body
must correspond to the number of dimensions (actual-parameters) of
the actual ARRAY (PROCEDURE).
3) Arithmetic type procedures used as parameters must have exact type
correspondence. For REF-procedures the actual type must coincide
with that if the formal parameter.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 181
CHAPTER 2.7.2
CONDITIONAL STATEMENTS
----------------------
Conditional statements cause certain statements to be executed or
skipped depending on the current values of certain conditions. They
provide an important structural framework in the language.
IF-statement
------------
** **
* *
* ** ** *
* * * *
* * WHILE-statement * *
* * * *
* * FOR-statement * *
* IF-clause ** ** *
* * connection-statement * *
* * * *
[label:]... ** * closed * **
* * * *
* ** ** *
* *
* IF-clause closed *
* *
* ELSE statement *
* *
** **
Examples:
---------
L: IF X > 0 THEN X := -X;
IF X = 0 AND Y = 0 THEN
L: BEGIN OUTTEXT("ORIGIN");
OUTIMAGE;
END;
X :- T;
WHILE X =/= NONE DO
BEGIN IF X QUA PERSON.MALE THEN MAN := MAN + 1
ELSE WOMAN := WOMAN + 1;
X :- X.SUC;
END;
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 182
CHAPTER 2.7.2
The statement sequence
IF condition THEN S1; S2
is equivalent to
(evaluate condition) S1; S2 if the condition is TRUE
(evaluate condition) S2 if the condition is FALSE.
The statement sequence
IF condition THEN S1 ELSE S2; T
is equivalent to
(evaluate condition) S1; T if the condition is TRUE, and
(evaluate condition) S2; T if the condition is FALSE.
A GOTO statement may lead directly into a conditional statement e.g.,
IF B THEN BEGIN OUTTEXT("TRUE");
L: OUTIMAGE;
END
ELSE BEGIN OUTTEXT("FALSE");
GOTO L;
END
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 183
CHAPTER 2.7.2
CONNECTION STATEMENTS
---------------------
Connection-statements constitute a form of remote accessing which is
mainly used as a user convenience if there are to be many accesses to
a particular object.
e.g.
we may replace
SYSBIN.INIMAGE;
X := SYSBIN.INREAL;
Y := SYSBIN.INREAL;
C := SYSBIN.INCHAR;
by
INSPECT SYSBIN DO
BEGIN INIMAGE;
X := INREAL;
Y := INREAL;
C := INCHAR;
END
Connection statement
--------------------
** **
* *
* statement *
INSPECT object-ref DO ** [WHEN CLASS-identifier DO statement]...**
erence * [OTHERWISE statement] *
* *
** **
Examples:
---------
INSPECT SYSOUT DO
BEGIN OUTTEXT("TITLE");
OUTIMAGE;
EJECT(LINE+10);
END;
INSPECT X WHEN A DO OUTTEXT("X IN A")
WHEN B DO OUTTEXT("X IN B")
OTHERWISE OUTTEXT("ERROR");
INSPECT X DO
INSPECT Y DO P := Q
OTHERWISE OUTTEXT("Y==NONE");
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 184
CHAPTER 2.7.2
To avoid ambiguity, an OTHERWISE refers back to the nearest INSPECT.
The remote accessing of objects of classes may be accomplished by the
dot notation or by connection. In most cases the methods are
interchangeable but if the object contains class attributes (local
classes), at level K, then attributes at levels KK >= K can only be
accessed by connection.
To access an attribute of an object we have to know:
1) a reference to the object
2) the qualification of the reference
3) the attribute identifier.
The two variations are now explained:
1) a) INSPECT X DO S1 OTHERWISE S2
b) INSPECT X DO S1
If X =/= NONE then the statement S1 is executed. During execution
of this statement the reference variable of X is evaluated once
and stored. Access is now gained to the denoted object at the
qualification level of X. All attributes of the qualifying class
are now available by the occurrence of their identifiers.
If X == NONE, then the statement S1 is skipped and the statement
S2 is executed in case a), and the whole connection statement is
skipped in case b).
In an otherwise branch, no connection holds.
e.g.
CLASS A;
BEGIN REAL X; ..... END;
A CLASS B
BEGIN BOOLEAN Y; .. END;
REF(A)Q; REF(B)Z;
INSPECT Q DO INSPECT Q QUA B DO
BEGIN X := 2; BEGIN X := 2;
THIS B.Y := FALSE; Y := FALSE;
Z :- NONE; Z :- NONE;
END END
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 185
CHAPTER 2.7.2
2) INSPECT X WHEN A DO S1
WHEN B DO S2
.....
OTHERWISE T
This descriminates on class membership at run time. The WHEN
clauses are considered in turn. If X is an object belonging to a
class equal to or inner to the one identified in the clause then
the associated statement is executed and the rest of the
connection-statement is skipped. The OTHERWISE-clause (if
present) is only executed if X == NONE or all preceding WHEN
clauses are skipped.
OBJECT GENERATORS
-----------------
Object-generators were discussed in section 2.6.7. They may also
stand as statements in their own right, in which case their reference
value is not assigned on exit. This does not mean that they cannot be
referenced as the following example shows:
LINK CLASS B(H); REF (HEAD)H;
BEGIN PTR :- THIS B;
INTO(H);
END
After execution of the statement
NEW B(HD);
then the generated object is referenced by PTR and HD.LAST
(if HD =/= NONE).
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 186
CHAPTER 3
CHAPTER 3 PROGRAM STRUCTURE AND SYSTEM FEATURES
-----------------------------------------------
3.1 PROGRAM STRUCTURE
-----------------
Without the CLASS concept, the run time structure of a SIMULA program
is essentially that of a stack of blocks with the last created block
"active". Given the program skeleton
BEGIN REAL X;
L1: S1;
BEGIN BOOLEAN B;
S2;
BEGIN TEXT X;
L3; S3;
END;
L2: S4;
END;
S5;
END
(where the S's denote statement sequences) then the structures at run
time are
1. during execution of S1 or S5
-----------------
! ! !
! ! !
-----------------
! REAL X ! PSC denotes the
-----------------
PSC --->! L1: S1 ! current statement
! <INNER BLOCK> !
! S5 !
-----------------
Only one variable REAL X exists.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 187
CHAPTER 3.1
2. during execution of S2 (or S4)
-----------------
! ! !<---
! ! ! !
----------------- !
! REAL X ! !
----------------- !
! L1; S1 ! !
--->! <INNER BLOCK> ! !
! ! S5 ! !
! ----------------- !
! !
! !
! ----------------- !
----!--. ! .--!----
! ! !
-----------------
! BOOLEAN B !
-----------------
PSC --->! S2 !
! <INNER BLOCK> !
! L2: S4 !
-----------------
Two varaibles REAL X and BOOLEAN B exist.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 188
CHAPTER 3.1
3. during execution of S3
-----------------
! ! . !<---
! ! ! !
----------------- !
! REAL X ! !
----------------- !
! L1: S1 ! !
--->! <INNER BLOCK> ! !
! ! S5 ! !
! ----------------- !
! !
! !
! ! STACK OF
! ----------------- !
----!--. ! .--!---- "ATTACHED"
! ! !<---
----------------- ! BLOCKS
! BOOLEAN B ! !
----------------- !
! S2 ! !
--->! <INNER BLOCK> ! !
! ! L2: S4 ! !
! ----------------- !
! !
! !
! !
! ----------------- !
--->!--. ! .--!----
! ! !
-----------------
! TEXT X !
-----------------
! !
PSC --->! L3: S3 !
! !
-----------------
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 189
CHAPTER 3.1
Three variables exist: REAL X, BOOLEAN B, TEXT X, but only two
are accessible by actions in the active block, for the REAL X of
the outermost block has become inaccessible due to an identifier
clash with TEXT X of the innermost block.
Note that besides exiting from a block via its final END, it is
also possible to exit via a GOTO-statement. If the statement
sequence S3 includes the statement
GOTO L2
then on execution of that statement, the innermost block is
deleted (the variable TEXT X will no longer exist).
If the statement sequence S3 includes the statement
GOTO L1
then both the inner blocks will be deleted when that statement is
executed and both BOOLEAN B and TEXT X will no longer exist.
The CLASS concept initially gives the opportunity for data structures
to exist in parallel. The program
BEGIN CLASS A;..........;
REF(A)U,V;
U :- NEW A;
BEGIN CLASS B;..........;
REF(B)X;
REF(A)W;
V :- W :- NEW A;
X :- NEW B;
L: ..........
END ***INNER BLOCK*** ;
..........
END ***PROGRAM*** ;
has the representation below at the label L.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 190
CHAPTER 3.1
------------------------------------
! !
V !
----------------- !
! ! !<----------------- !
OB: outer block ! OB ! !<--- ! !
----------------- ! ! !
! CLASS A ! ! --------- ---------
! REF(A) U .--!---!------>! ! . ! --->! ! . !
! REF(A) V .--!---!---- --------- ! ---------
----------------- ! ! ! ! ! ! ! !
! <INNER BLOCK> ! ! ! ! ! ! ! ! !
! ............ ! ! ! --------- ! ! ---------
----------------- ! ! ! !
! ---------------- !
! !
----------------- ! !
IB: inner block ! IB ! .--!---^ <------- !
----------------- >-------!------------
! CLASS B ! ^ !
! REF(A) W .--!---- ---------
! REF(B) X .--!----->! ! . !
----------------- ---------
! .......... ! ! !
! L: ....... ! ! !
----------------- ---------
When the inner block is deleted, the second A object is still
available as it is referenced by V. On the other hand, the B object
must be deleted as its declaration disappears and therefore no
references exist.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 191
CHAPTER 3.1
At this level, the actions of each object are executed until
exhaustion and then the object is left as an attribute structure in
the terminated state. But there is a broad class of problems which
cannot be modelled by this mechanism, e.g., when the actions are
executed in phases corresponding to the actual concept represented
being active or passive. For example, a customer in a shop goes
through the stages of queuing (passive) and buying (active), players
in a game of cards play, and then are passive until their turn comes
again. We could picture a customer object, C, by:
-----------------
! ! !
! ! !
C------>-----------------
! enter shop !
! !...active
! enter queue 1 !
! !
! !
! ! . . . passive
! !
! !
! served !
! !...active
! enter queue 2 !
! !
! !
! ! . . . passive
! !
! !
! served !
! !...active
! enter queue 3 !
! !
!...............!
! !
! leave shop !
! !
-----------------
When C is passive its actions may be made active again by a call
RESUME(C). The actions of C are resumed from where they were left off
last. To mark off this program point objects can be made into program
components supplied with a LOCAL SEQUENCE CONTROL (LSC) which marks
the current stage of execution of their actions.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 192
CHAPTER 3.1
A very simple example is that of two players playing a game. Their
actions may be loosely described by
..........
L: play
RESUME(opponent);
GOTO L
When the first player is generated, we do not wish to execute these
actions as the opponent is not yet generated. So we have to return
control to the main block and return a reference to this player, and
then create the second player. A second system PROCEDURE DETACH
serves this purpose. On meeting DETACH, the object becomes a system
component with an LSC referencing the next statement, control is
returned to its object generator and with it a reference to the
object.
The outline of a simple program for a two man game is:
BEGIN CLASS PLAYER;
BEGIN REF(PLAYER) OPPONENT;
DETACH;
L: play;
RESUME(OPPONENT);
GOTO L
END;
REF(PLAYER)P1,P2;
P1 :- NEW PLAYER;
P2 :- NEW PLAYER;
P1.OPPONENT :- P2; P2.OPPONENT :- P1;
RESUME(P1);
..........
END
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 193
CHAPTER 3.1
A snapshot at the point where RESUME(P1) has just been executed is:
----------------------
--! MB ! !
! ----------------------
! ! PLAYER CLASS !
! ! P1 REF(PLAYER).!----
! ! P2 REF(PLAYER).!---!---
! ! ............ ! ! !
! ! RESUME(P1) ! ! !
LSC ->! ............ ! ! !
---------------------- ! !
! !
! !
! !
----------------------- !
! ! <--------
! ! !
! ! !
V V !
------------------------ !--->------------------------ !
--!-. ! MB ! ! --!-. ! MB ! !
! ------------------------ ! ! ------------------------ !
! ! OPPONENT REF(PLAYER).!--- ! ! OPPONENT REF(PLAYER).!---
! ! DETACH ! LSC->! DETACH !
LSC,PSC ->! L: PLAY ! ! L: PLAY !
! RESUME(OPPONENT) ! ! RESUME(OPPONENT) !
! GOTO L ! ! GOTO L !
------------------------ ------------------------
The PSC coincides with the LSC of the currently active component.
After P1 has played, P2 is resumed and the new snapshot is:
-----------------
---!---. MB ! !
! -----------------
! ! .......... !
! ! !
LSC -->! RESUME(P1) !
! !
! .......... !
-----------------
----------------------- -----------------------
---!------. ! MB ! ---!------. ! MB !
! ----------------------- ! -----------------------
! ! .......... ! ! ! .......... !
! ! L: play ! LSC,PSC -->! L: PLAY !
LSC -->! RESUME(OPPONENT) ! ! RESUME(OPPONENT) !
! GOTO L ! ! GOTO L !
----------------------- -----------------------
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 194
CHAPTER 3.1
Note that there are three components here with LSC's: the two players
and the program block. The current state of the two objects is
"detached" - when they are program components with LSC's. When their
actions are exhausted, they lose their LSC's and become "terminated".
Control returns to the main program block and continues from its LSC.
Only a "detached" object may be resumed.
One question remains: how to transfer control back to the
(unreferenced) main program block without terminating an object. This
is achieved by a further call on DETACH.
In addition to sequencing PROCEDURES, "DETACH" and "RESUME", there is
the PROCEDURE CALL which has one reference parameter which must be a
reference to a detached object.
The execution of CALL(Y) from within a block X, will "attach" the
detached object Y to X and continue execution of the actions of Y.
The detailed description of program sequencing given in the "SIMULA 67
Common Base Language" is not repeated here. Further enquiries are
directed to that document.
Semaphore variables to control critical regions are normally not
necessary in SIMULA, since control is only passed between parallel
processes by explicit commands. However, it is very easy to program
semaphore variables as a CLASS semaphore.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 195
CHAPTER 3.2
3.2 THE SYSTEM CLASS SIMSET
-----------------------
List processing concepts and list manipulating procedures are declared
in the system classes within the CLASS SIMSET. SIMSET can be used as
a block prefix or as a prefix to another CLASS at one and only one
block level in a program.
In SIMSET are provided the concepts for manipulating two-way lists
called "sets". Besides the set members which carry information and
are prefixed by LINK, a set also has a HEAD which has attributes
giving global information about the set (e.g., how many members it
has).
A set is organised on the basis of references SUC and PRED which are
common to LINK and HEAD.
------------
H ---->! . SUC ! SET HEAD
! ! !
! ! PRED .-!-------------------
--!--------- !
! !
!---- !
V !
----------- ----------- -----------
! SUC .---!---->! SUC .---!---->! SUC ! SET MEMBERS
! ! ! ! ! ! PREFIXED BY
! PRED !<----!-. PRED !<----!-. PRED ! LINK
----------- ----------- -----------
To protect the user from certain kinds of error, SUC and PRED are made
REF(LINK) PROCEDURES and so may not be assigned to.
The part common to both HEAD and LINK is declared separately in CLASS
LINKAGE which is then used as a prefix to HEAD and LINK.
A skeleton of the CLASS SIMSET is thus
CLASS SIMSET;
BEGIN CLASS LINKAGE............;
LINKAGE CLASS LINK.......;
LINKAGE CLASS HEAD.......;
END ***SIMSET***
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 196
CHAPTER 3.2
This hierarchy may be pictorially represented by:
--------
! PREV !
--------
! SUC !
--------
! PRED !
------------------------------------
! LINKAGE !
! !
! !
! !
V V
------------ -----------
! FIRST ! ! OUT !
! LAST ! ! INTO !
! EMPTY ! ! PRECEDE !
! CARDINAL ! ! FOLLOW !
! CLEAR ! -----------
------------
LINK
HEAD
in which the procedures local to each of the classes are denoted by
their identifiers.
An outline of the individual classes is now given containing the
procedure-headings and a prose description of their actions.
Throughout the prose descriptions which are illustrated by
representative calls, we assume that the declarations
REF(HEAD)HD;
REF(LINK)LK;
REF(LINKAGE)LG;
are valid.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 197
CHAPTER 3.2
CLASS LINKAGE
-------------
CLASS LINKAGE;
BEGIN REF(LINK) PROCEDURE SUC;.....;
REF(LINK) PROCEDURE PRED;....;
REF(LINKAGE) PROCEDURE PREV;.;
END ***OF LINKAGE*** ;
REF(LINK) PROCEDURE SUC;.....;
LK.SUC returns a reference to the succeeding set member
if LK is in a set, and LK is not the last member
of the set, otherwise it returns NONE.
HD.SUC returns a reference to the first set member if the
set is not empty, otherwise NONE.
REF(LINK) PROCEDURE PRED;....;
LK.PRED returns a reference to the preceding set member if
LK is in a set and LK is not the first member of
the set, otherwise NONE.
HD.PRED returns a reference to the last set member if the
set is not empty, otherwise NONE.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 198
CHAPTER 3.2
REF(LINKAGE) PROCEDURE PREV;....;
LK.PREV returns NONE if LK is not in a set, a reference to
the set head if LK is first member of a set,
otherwise it returns a reference to LK's
predecessor.
HD.PREV returns a reference to HD if HD is empty,
otherwise a reference to the last member of the
set with head HD.
NOTE
By following PREV it is possible to give
a reference to the head of a set in
which a LINK object is a member, as
shown in the following procedure (not
local to LINKAGE, LINK or HEAD).
REF(HEAD) PROCEDURE THESETHEADOF(LK); REF(LINK)LK;
BEGIN REF(LINKAGE)X;
IF LK =/= NONE THEN
BEGIN X :- LK.PREV;
WHILE X IN LINK DO
X :- X.PREV;
THESETHEADOF :- X;
END;
END ***THESETHEADOF***
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 199
CHAPTER 3.2
CLASS HEAD
----------
LINKAGE CLASS HEAD;
BEGIN PROCEDURE CLEAR;................;
REF(LINK) PROCEDURE FIRST;......;
REF(LINK) PROCEDURE LAST;.......;
BOOLEAN PROCEDURE EMPTY;........;
INTEGER PROCEDURE CARDINAL;.....;
END ***OF HEAD***
REF(LINK) PROCEDURE FIRST;.....;
HD.FIRST is equivalent to HD.SUC
REF(LINK) PROCEDURE LAST;.....;
HD.LAST is equivalent to HD.PRED
BOOLEAN PROCEDURE EMPTY;.....;
HD.EMPTY returns TRUE if HD references a set with no
members, FALSE if HD references a set with one or
more members.
INTEGER PROCEDURE CARDINAL;.....;
HD.CARDINAL returns how many members the set HD contains (0 if
HD is empty).
PROCEDURE CLEAR;.....;
HD.CLEAR removes all members from the set, making it empty.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 200
CHAPTER 3.2
CLASS LINK
----------
LINKAGE CLASS LINK;
BEGIN PROCEDURE OUT;..........;
PROCEDURE INTO(H); REF(HEAD)H;..........;
PROCEDURE PRECEDE(X); REF(LINKAGE)X;....;
PROCEDURE FOLLOW(X); REF(LINKAGE)X;.....;
END ***OF LINK***
PROCEDURE OUT;.....;
LK.OUT removes LK from a set and re-establishes the SUC,
PRED connections between its previously
neighbouring members. If LK was not a set member,
no action is taken.
PROCEDURE INTO(H); REF(HEAD)H;......;
LK.INTO(HD) LK.OUT is called first. If HD == NONE no action
is taken. If HD =/= NONE, LK goes into the set HD
as the new last member.
PROCEDURE PRECEDE(X); REF(LINKAGE)X;......;
LK.PRECEDE(LG) LK.OUT is called first. If LG == NONE or is not
in a set then no action is taken, otherwise LK
goes into the same set as LG as the new LG.PRED
(LG may reference either a HEAD or a LINK object).
PROCEDURE FOLLOW(X); REF(LINKAGE)X;......;
LK.FOLLOW(LG) as PRECEDE except that LK becomes the new LG.SUC
The use of reference variables and the fact that an object of any
CLASS inner to CLASS LINK may be inserted in a set give the following
desirable features:
1) ordered sets can be manipulated by efficient standard procedures
2) both the successor and predecessor of a LINK object are
immediately accessible
3) the set members can be objects of different classes.
Note that a LINK object can only be in one set at a time.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 201
CHAPTER 3.2
Example on the use of SIMSET
----------------------------
The example is concerned with the dealing of a hand of cards, 13 cards
each in rotation, to a table of four players. It shows how the
concepts HEAD and LINK of SIMSET may be used as a platform upon which
to build more general concepts.
The patterns to be described are
CLASS CARD
CLASS DECK
CLASS HAND
Initially the CARD objects are created and inserted into a DECK in the
order of their generation (which is non-random). Skeletons of these
two CLASSES are
LINK CLASS CARD(COLOUR,RANK); INTEGER COLOUR, RANK;
BEGIN.......................................... END;
HEAD CLASS DECK;
BEGIN ..... END;
Immediately prior to the dealing, the situation may be represented by
--------
CARDDECK---> ---! HEAD !-------------------
! -------- !
! ! DECK ! !
! -------- !
! !
! !
! !
V V
------------<-->------------<- ... ->------------
CARD ! LINK ! ! LINK ! ! LINK !
------------ ------------ ------------
OBJECTS ! COLOUR 1 ! ! COLOUR 2 ! ! COLOUR 4 !
! RANK 1 ! ! RANK 1 ! ! RANK 13 !
------------ ------------ ------------
A deal consists of removing the 52 cards in random order from CARDDECK
and inserting them into the HANDS in rotation.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 202
CHAPTER 3.2
It is convenient to describe each HAND by
CLASS HAND;
BEGIN REF(HEAD) ARRAY SUIT[1:4];
generate four heads representing the four
possible suits;
END ***HAND***
After generation and the dealing of the CARDS, a HAND object can be
visualised by:
----------- --- --- --- ---
! SUIT[1] !--->! ! ! ! ! ! ! ! 4 CLUBS
! ! --- --- --- ---
----------- --- --- ---
! SUIT[2] !--->! ! ! ! ! ! 3 DIAMONDS
! ! --- --- ---
----------- --- ---
! SUIT[3] !--->! ! ! ! 2 HEARTS
! ! --- ---
----------- --- --- --- ---
! SUIT[4] !--->! ! ! ! ! ! ! ! 4 SPADES
! ! --- --- --- ---
-----------
Now the CARDS may be ranked in order of their attribute RANK and in
the appropriate SUIT. The actions of the program are:
Generate the deck;
Deal the hands;
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 203
CHAPTER 3.2
Generate the deck
-----------------
These actions may be made local to CLASS DECK, which now has the
outline
HEAD CLASS DECK;
BEGIN INTEGER I,J;
FOR J := 1 through 13 DO
FOR I := 1 through 4 DO
NEW CARD(I,J).INTO(THIS HEAD)
END ***DECK***
On generation of a DECK object, the representation of the CARDS is
automatically generated.
Deal the hands
--------------
This part consists of randomly selecting the Nth card and placing it
in the appropriate SUIT of the current PLAYER. Let J denote the index
of the current PLAYER (J = 1,2,3 or 4), then the actions are:
J := 0;
FOR I := 52 STEP -1 UNTIL 1 DO
BEGIN C :- the randomly selected card;
IF J = 4 THEN J := 1 ELSE J := J + 1;
COMMENT ***SELECT INDEX OF CURRENT PLAYER*** ;
place C in PLAYER(J)
END;
There remains the tasks of writing the selection procedure, and the
procedure to place the CARD C in the current HAND. These are done by
PROCEDURE SELECT local to CLASS DECK and PROCEDURE PLACE local to
CLASS HAND.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 204
CHAPTER 3.2
The final program is:
SIMSET
BEGIN HEAD CLASS DECK;
BEGIN REF(CARD) PROCEDURE SELECT(N); INTEGER N;
BEGIN REF(CARD)X; INTEGER I;
X :- FIRST QUA CARD;
FOR I := 2 STEP 1 UNTIL N DO
X :- X.SUC;
SELECT :- X;
END ***SELECT*** ;
INTEGER I,J;
FOR I := 1 STEP 1 UNTIL 13 DO
FOR J := 1 STEP 1 UNTIL 4 DO
NEW CARD(J,I).INTO(THIS HEAD);
END ***DECK*** ;
LINK CLASS CARD(COLOUR,RANK); INTEGER COLOUR, RANK;;
COMMENT ***COLOUR = 1 REPRESENTS CLUBS
2 REPRESENTS DIAMONDS
3 REPRESENTS HEARTS
4 REPRESENTS SPADES
RANK = 1 REPRESENTS ACE
2-10 OBVIOUS
11 JACK
12 QUEEN
13 KING*** ;
CLASS HAND;
BEGIN PROCEDURE PLACE(C); REF(CARD)C;
BEGIN REF(HEAD)S; REF(CARD)X;
S :- SUIT[C.COLOUR];
IF NOT S.EMPTY THEN
BEGIN X :- S.FIRST QUA CARD;
WHILE X =/= NONE DO
BEGIN IF X.RANK > C.RANK THEN
BEGIN C.PRECEDE(X);
GOTO L;
END;
X:- X.SUC;
END;
END;
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 205
CHAPTER 3.2
COMMENT ***WE ENTER HERE IF S IS EMPTY OR
IF C.RANK IS THE HIGHEST MET
SO FAR*** ;
C.INTO(S);
L: END ***PLACE*** ;
REF(HEAD) ARRAY SUIT[1:4];
SUIT[1] :- NEW HEAD;
SUIT[2] :- NEW HEAD;
SUIT[3] :- NEW HEAD;
SUIT[4] :- NEW HEAD;
END ***HAND*** ;
REF (CARD) C;
REF (DECK) CARDDECK;
INTEGER I,J,U;
REF(HAND) ARRAY PLAYER[1:4];
U := ININT; COMMENT ***INPUT THE RANDOM STREAM BASE*** ;
CARDDECK :- NEW DECK;
COMMENT ***GENERATES THE WHOLE PACK OF 52 CARDS IN
NON-RANDOM ORDER***;
FOR I := 1 STEP 1 UNTIL 4 DO
PLAYER[I] :- NEW HAND;
FOR I := 52 STEP -1 UNTIL 1 DO
BEGIN C :- CARDDECK.SELECT(RANDINT(1,I,U));
IF J = 4 THEN J := 1 ELSE J := J + 1;
PLAYER[J].PLACE(C);
END;
END ***PROGRAM***
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 206
CHAPTER 3.3
3.3 THE SYSTEM CLASS SIMULATION
---------------------------
The CLASS SIMULATION is prefixed by SIMSET and provides, in addition
to SIMSET's set concepts, the notions of a time axis and processes
(entities which interact over a period of time).
The time axis consists of a set of event notices which have two
attributes, a reference to the PROCESS they represent (PROC) and the
time of its next scheduled event (EVTIME). The event notices are
ranked according to the values of the time variable (EVTIME). We can
picture the time axis with four scheduled events by:
************** *************** *************** ***************
EVENT * EVTIME 5.0 * * EVTIME 10.0 * * EVTIME 11.0 * * EVTIME 11.0 *
NOTICES * PROC . * * PROC . * * PROC . * * PROC . *
************** *************** *************** ***************
! ! ! !
! ! ! !
V V V V
************** *************** *************** ***************
--*-- . * * --*-- . * * --*-- . * * --*-- . * *
! ************** ! *************** ! *************** ! ***************
! * * ! * * ! * * ! * *
! * * ! * L: DETACH; * ! * * ! * *
->* * ->* GOTO L; * ->* * ->* *
* * * * * * * *
************** *************** *************** ***************
^ ^
! !
! !
CURRENT MAIN
The first PROCESS represented in the time axis is always referenced by
CURRENT and the system time is the value of its scheduled next event
(here 5.0). An object of any class prefixed by PROCESS may take an
active and passive part in a simulation. The organization is so
framed that the PSC lies within CURRENT and its actions are executed.
When the active phase if over, that PROCESS may be rescheduled for a
later active phase (for example, by REACTIVATE or HOLD) or removed
from the timing tree (by PASSIVATE or WAIT). It is apparent that
RESUME is too primitive for this purpose since rescheduling or
removing EVENT NOTICES is involved as well as switching the PSC from
one PROCESS object to another.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 207
CHAPTER 3.3
However, RESUME and DETACH do form the basis for the scheduling
procedures. To prevent the user from destroying system security,
event notices may not be explicitly referenced by the user - he must
use the system procedures for scheduling or rescheduling. In
addition, it is strongly recommended that explicit use of "DETACH",
"RESUME" and "CALL" be avoided within a SIMULATION block.
There is one special PROCESS object which plays a key role in any
SIMULATION - one referenced by MAIN. Whenever MAIN becomes CURRENT,
it causes the actions of the SIMULATION block itself to be continued.
The corresponding event notice can then be rescheduled (typically by a
call on HOLD) and then the action switches from the SIMULATION block
to the new CURRENT. Thus the SIMULATION block is itself treated as a
program component during the SIMULATION.
The class outline is
SIMSET CLASS SIMULATION;
BEGIN LINK CLASS PROCESS.....;
REF(PROCESS) PROCEDURE CURRENT;.....;
REAL PROCEDURE TIME;.....;
COMMENT ***SCHEDULING PROCEDURES*** ;
PROCEDURE HOLD;.......;
PROCEDURE PASSIVATE;..;
PROCEDURE WAIT;.......;
PROCEDURE CANCEL;.....;
PROCEDURE ACTIVATE;...;
PROCEDURE ACCUM;......;
REF("the main program")MAIN;
COMMENT ***HERE FOLLOW ACTIONS WHICH SET UP THE
TIME AXIS AT TIME ZERO*** ;
END ***SIMULATION***
We now give a prose discussion of the attributes of CLASS SIMULATION:
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 208
CHAPTER 3.3
CLASS PROCESS
-------------
LINK CLASS PROCESS;
BEGIN BOOLEAN PROCEDURE IDLE;..........;
BOOLEAN PROCEDURE TERMINATED;....;
REAL PROCEDURE EVTIME;...........;
REF(PROCESS) PROCEDURE NEXTEV;...;
DETACH;
INNER;
PASSIVATE;
END ***PROCESS***
An object of a class inner to CLASS PROCESS is a PROCESS object. A
PROCESS object has the properties of CLASS LINK and can be manipulated
by sequencing statements. Sequencing statements are used to insert or
delete a PROCESS object from the time axis. The state of a PROCESS
object after generation is "detached" and its LSC is positioned to the
first statement of the user defined operations rule. When the actions
of the user defined subclass are exhausted, the unfinished actions of
the PROCESS level are continued (following the INNER). These remove
the object from the time axis (PASSIVATE) and its state becomes
"terminated".
If a PROCESS object is not represented in the time axis, then it is
terminated or passive (its actions are not yet exhausted) and the
BOOLEAN PROCEDURE IDLE returns TRUE. All PROCESS objects represented
in the time axis are said to be suspended except for the first
(CURRENT) which is said to be active.
A call on EVTIME for a suspended or active PROCESS object returns the
scheduled time of its next event. If the object is passive or
terminated, then a call on EVTIME results in a run time error.
-----------------------------------------------------------
! PROCESS ! !
! object ! result of procedure call !
-----------------------------------------------------------
! state ! IDLE ! TERMINATED ! EVTIME !
-----------------------------------------------------------
! active ! FALSE ! FALSE ! time of current event !
! suspended ! FALSE ! FALSE ! time of next event !
! passive ! TRUE ! FALSE ! run time error !
! terminated ! TRUE ! TRUE ! run time error !
-----------------------------------------------------------
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 209
CHAPTER 3.3
REF(PROCESS) PROCEDURE CURRENT;......;
returns a reference to the currently active
PROCESS object. There is one special PROCESS
object in the system referenced by MAIN. Every
time MAIN becomes CURRENT it causes the actions of
the SIMULATION block to be resumed.
REAL PROCEDURE TIME;.....;
always returns the current value of the system
time.
PROCEDURE HOLD(T); REAL T;......;
HOLD(N) reschedules CURRENT so that its next
active phase will occur at TIME + N. If the value
of the actual parameter N is negative, the call is
equivalent to HOLD(0). After the rescheduling,
the actions of CURRENT are resumed.
Notice that HOLD(T) can be called from the user
defined SIMULATION block in which case MAIN will
be rescheduled - i.e., the actions of the program
block are suspended for N time units.
PROCEDURE PASSIVATE;......;
removes CURRENT from the time axis and resumes the
actions of the new CURRENT. A run time error will
occur if the time axis is now empty.
PROCEDURE WAIT(S); REF(HEAD)S;......;
PROCEDURE WAIT(S); REF(HEAD)S;
BEGIN CURRENT.INTO(S);
PASSIVATE
END ***WAIT***
WAIT includes the currently active PROCESS object
(this could be MAIN) into a referenced set, and
then calls PASSIVATE.
PROCEDURE CANCEL(X); REF(PROCESS)X;......;
CANCEL(P) where P is a reference to a PROCESS
object will delete the corresponding event notice
if any. If P is currently active or suspended, it
thus becomes passive. If P is a reference to a
passive or terminated PROCESS object or NONE,
CANCEL(P) has no effect. Thus CANCEL(CURRENT) is
equivalent to PASSIVATE.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 210
CHAPTER 3.3
PROCEDURE ACTIVATE
------------------
For user convenience, calls on the procedure ACTIVATE are written in
terms of the corresponding activation-statements.
activation-statement
--------------------
** ** ** **
* ACTIVATE * * [AT/DELAY time][PRIOR] *
** ** PROCESS-expression1 ** [BEFORE/AFTER]PROCESS **
* REACTIVATE * * expression2 *
** ** ** **
Let X be the value of PROCESS-expression1. If the activator ACTIVATE
is used, then the activation-statement will have no effect (other than
evaluating X) unless X is passive. If the activator REACTIVATE is
used, then X may be active, suspended, or passive (in which latter
case, the activation-statement acts as an ACTIVATE statement).
The type of scheduling is determined by the form of the activation
statement.
Direct activation
-----------------
** **
* ACTIVATE X *
** REACTIVATE X **
* *
** **
X becomes the new CURRENT and the system time is unchanged. The
formerly active PROCESS object from where the call was made becomes
suspended.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 211
CHAPTER 3.3
Timing clause
-------------
** ** ** **
*ACTIVATE * * AT *
** ** X ** ** T [PRIOR]
* REACTIVATE * * DELAY *
** ** ** **
The timing clause AT specifies the system time of the scheduled active
phase. The clause
DELAY T
is equivalent to
AT current-system-time + T
The corresponding EVENT NOTICE is inserted according to the specified
time, normally after any EVENT NOTICE with the same system time; the
symbol PRIOR may be used to specify insertion in front of any EVENT
NOTICE with the same system time.
Default actions
---------------
"AT T", when T < the current-system-time, is equivalent to "AT
current-system-time".
DELAY T when T < 0 is equivalent to DELAY 0.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 212
CHAPTER 3.3
Relative activation
-------------------
** ** ** **
* ACTIVATE * * BEFORE *
** ** X ** ** Y
* REACTIVATE * * AFTER *
** ** ** **
If Y is a reference to an active or suspended PROCESS object, then the
clause BEFORE Y or AFTER Y is used to insert an event notice for X
before or after that of Y and at the same system time.
Default actions
---------------
If Y is neither active nor suspended, then the activation-statement is
equivalent to
CANCEL(X).
If X == Y, then the activation-statement is equivalent to
CANCEL(X).
PROCEDURE ACCUM
---------------
PROCEDURE ACCUM(A,B,C,D); NAME A,B,C; REAL A,B,C,D;
BEGIN A := A + C*(TIME-B);
B := TIME;
C := C + D
END ***ACCUM***
ACCUM(P,Q,R,S) is used to accumulate the "system time integral" of the
variable R. The accumulation takes place in P. The integral is
interpreted as a step function of the system time with Q holding the
system time when P was last updated. The value of S is the current
increment of the step function.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 213
CHAPTER 3.3
Before
------
^
!
!
--!--
S !
--!--
!
!
!
!
!
! ------------ **
! !//////////! *
! ----------!//////////! *
! !/////////!//////////! ** R
!-----------!/////////!//////////! *
!///////////!/////////!//////////! *
!///////////!/////////!//////////! **
---------------------------------.--------------->
^
!
Q time
TIME
After a call on ACCUM(P,Q,R,S) we have
^
!
!
!
!
!
! ------------ **
! !//////////! *
! -----------!//////////! *
! !//////////!//////////! *
! -----------!//////////!//////////! ** R
! !//////////!//////////!//////////! *
!----------!//////////!//////////!//////////! *
!//////////!//////////!//////////!//////////! *
!//////////!//////////!//////////!//////////! **
--------------------------------------------.------------>
^
!
Q
TIME
P contains result so far (shaded area).
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 214
CHAPTER 3.3
Example on the use of SIMULATION
--------------------------------
The program is a description of a simple epidemic model. A
contagious, non-lethal disease is spreading through a POPULATION of a
fixed size. Certain countermeasures are taken by a public health
organization. Each individual infection has a given INCUBATION
period, during which the subject is noncontagious and has no SYMPTOMS,
followed by a contagious period of a given LENGTH.
COURSE OF INFECTION IN DAYS
* * * *
* INCUBATION * LENGTH * thereafter *
********************************************
NON-CONTAGIOUS CONTAGIOUS IMMUNE
Each DAY of the contagious period the subject may seek TREATMENT from
the public health organisation and get cured. The probability of his
seeking treatment is stored in REAL ARRAY PROBTREAT [1:LENGTH]. Each
person has an expected number of CONTACTS per day. At one such
contact the probability of infecting a previously uninfected person is
PROBINFECT.
Once cured a person becomes immune. If untreated, the infection
ceases after the given period and the person becomes immune.
SICKP (sick persons) appear as PROCESSes in the system. When CURED,
or when the disease has run its course, they leave the system. The
very first infection is generated by the main program (user block). A
person infected by another person is included as a member in a set
belonging to the infector (his environment (ENV)). A person can be a
member of at most one set.
As people are cured, they are removed from these sets which gradually
split up into smaller sets. The latter grow independently,
disintegrate further, and so on. As the number of UNINFECTED people
decreases, the growth of the contagion slows down until it finally
dies out.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 215
CHAPTER 3.3
The public countermeasures are represented by TREATMENTs which are
also PROCESSes. A patient is removed from the environment set to
which he belongs, if any. If he has visible symptoms, he is cured.
In addition his environment is searched and each member is subjected
to a full treatment which may cause other environments to be searched
etc. A patient displaying no symptoms is given a mass treatment which
has a probability PROBMASS of success. His environment is not
searched. In the present model, treatments act instantaneously. The
simulation ends after SIMPERIOD units of time.
An outline of the problem description is
SIMULATION
BEGIN PROCESS CLASS SICKP;
BEGIN REF(HEAD)ENV;
PROCEDURE INFECT;
......
END ***SICK PERSON*** ;
PROCESS CLASS TREATMENT(PATIENT);
REF(SICKP)PATIENT;
BEGIN ...................... END;
..........
END ***SIMULATION BLOCK*** ;
We may now outline the class actions
PROCESS CLASS SICKP;
BEGIN PROCEDURE INFECT;......;
INTEGER TODAY; BOOLEAN SYMPTOMS;
REF(HEAD)ENV;
COMMENT ***wait incubation days for symptoms to
appear*** ;
HOLD(incubation period);
COMMENT ***now the symptoms are apparent. If
"treatment today" is TRUE then a cure
is sought which also implies that the
environment of this SICK PERSON is
examined. Also a number of contacts
are infected*** ;
SYMPTOMS := TRUE;
FOR TODAY := 1 through LENGTH DO
BEGIN
IF treatment today THEN ACTIVATE NEW TREATMENT;
INFECT(todays contacts);
HOLD(1);
END;
END ***SICK PERSON*** ;
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 216
CHAPTER 3.3
PROCEDURE INFECT(N); INTEGER N;
BEGIN INTEGER I;
COMMENT ***N gives the number of contacts who can
be infected. N random drawings are made
to see if the N contacts are to be infected.
If so a NEW SICKP is generated
and included in this SICKPs ENV and
activated*** ;
FOR I := 1 through N DO
IF Ith contact is infected THEN
BEGIN NEW SICKP.INTO(ENV);
ACTIVATE ENV.LAST;
END;
END ***INFECT***
PROCESS CLASS TREATMENT(PATIENT); REF(SICKP)PATIENT;
BEGIN REF(SICKP)X;
INSPECT PATIENT WHEN SICKP DO
BEGIN OUT;
IF SYMPTOMS THEN
BEGIN CANCEL(PATIENT);
FOR X :- ENV.FIRST WHILE X =/= NONE DO
ACTIVATE NEW TREATMENT(X);
END ELSE IF mass treatment successful
THEN CANCEL(PATIENT)
END;
END ***TREATMENT***
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 217
CHAPTER 3.3
Explanation:
------------
A treatment tests the SYMPTOMS attribute of its parameter PATIENT. If
TRUE then the instantaneous successful treatment is given. The
patient is removed from the set he is in (OUT) and becomes passive for
the rest of the simulation. In addition his environment is searched
and a new treatment is activated for each member. If there are no
symptoms, the patient is given a cheap pill which has a probability of
being successful. If successful the patient is instantaneously cured
and takes no further part in the simulation, but his environment is
not searched.
A complete description of the program now follows:
BEGIN INTEGER POPULATION, LENGTH, CONTACTS, INCUBATION,
UNINFECTED, U1, U2, U3, U4, I, NSICK;
REAL PROBINFECT, PROBMASS, SIMPERIOD;
COMMENT ***THE RANDOM STREAM BASES ARE READ IN*** ;
U1 := ININT; U2 := ININT;
U3 := ININT; U4 := ININT;
UNINFECTED:= POPULATION := ININT;
INCUBATION := ININT; LENGTH := ININT;
CONTACTS := ININT;
SIMPERIOD := INREAL;
PROBINFECT := INREAL; PROBMASS := INREAL;
SIMULATION BEGIN REAL ARRAY PROBTREAT[1:LENGTH];
BOOLEAN PROCEDURE THISPERSONCAUGHTIT;
THISPERSONCAUGHTIT:=
DRAW(PROBINFECT*UNINFECTED/POPULATION,U3);
BOOLEAN PROCEDURE TREATED(DAY);
INTEGER DAY;
TREATED:= DRAW(PROBTREAT[DAY],U1);
BOOLEAN PROCEDURE
MASSTREATMENTSUCCESSFULL;
MASSTREATMENTSUCCESSFULL:=
DRAW(PROBMASS,U4);
PROCESS CLASS SICKP;
BEGIN INTEGER TODAY;
BOOLEAN SYMPTOMS;
REF(HEAD)ENV;
PROCEDURE INFECT(N); INTEGER N;
BEGIN INTEGER J;
FOR J := 1 STEP 1 UNTIL N DO
IF THISPERSONCAUGHTIT
THEN
BEGIN NEW SICKP.INTO(ENV);
ACTIVATE ENV.LAST;
END;
END ***INFECT*** ;
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 218
CHAPTER 3.3
NSICK:= NSICK + 1;
IF UNINFECTED > 0 THEN
UNINFECTED := UNINFECTED-1;
ENV :- NEW HEAD;
COMMENT ***NO SYMPTOMS APPEAR UNTIL
AFTER INCUBATION DAYS***
;
HOLD(INCUBATION); SYMPTOMS := TRUE;
COMMENT ***NOW SYMPTOMS APPEAR AND
THIS SICK PERSON MAY SEEK A
CURE AND INFECT OTHERS EACH
DAY*** ;
FOR TODAY := 1 STEP 1 UNTIL LENGTH DO
BEGIN IF TREATED(TODAY) THEN
ACTIVATE NEW TREATMENT(CURRENT);
INFECT(POISSON(CONTACTS,U2));
HOLD(1)
END;
NSICK:= NSICK - 1;
END ***SICK PERSON*** ;
PROCESS CLASS TREATMENT(PATIENT);
REF(SICKP)PATIENT;
BEGIN REF(SICKP)X;
INSPECT PATIENT WHEN SICKP DO
BEGIN OUT;
IF SYMPTOMS THEN
BEGIN CANCEL(PATIENT);
NSICK:= NSICK - 1;
FOR X :- ENV.FIRST WHILE X =/= NONE DO
ACTIVATE NEW TREATMENT(X);
END ELSE IF MASSTREATMENTSUCCESSFULL
THEN
BEGIN NSICK:= NSICK - 1;
CANCEL(PATIENT);
END;
END;
END ***TREATMENT*** ;
PROCESS CLASS SPY;
BEGIN
WHILE TRUE DO
BEGIN
OUTINT(TIME,4); SETPOS(NSICK+6);
OUTCHAR('*'); OUTIMAGE;
HOLD(1);
END LOOP;
END ***SPY***;
ACTIVATE NEW SICKP;
ACTIVATE NEW SPY DELAY 0;
FOR I:= 1 STEP 1 UNTIL LENGTH DO
PROBTREAT[I]:= INREAL;
HOLD(SIMPERIOD);
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 219
CHAPTER 3.3
END ***SIMULATION BLOCK*** ;
END ***PROGRAM***
IF SYSIN contains:
1 3 5 7
100 3 7
40 30 0.20 0.1
0.75 0.6 0.5 0.45 0.4 0.4 0.35
The resulting output will be:
0 *
1 *
2 *
3 *
4 *
5 *
6 *
7 *
8 *
9 *
10 *
11 *
12 *
13 *
14 *
15 *
16 *
17 *
18 *
19 *
20 *
21 *
22 *
23 *
24 *
25 *
26 *
27 *
28 *
29 *
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 220
CHAPTER 3.4
3.4 TEXT HANDLING FACILITIES
------------------------
The concept of TEXT is the key to SIMULA's input/output facilities.
For example when a card is read in, the internal representation is
held as a string of 80 CHARACTERS with a one to one correspondence
between the nth column of the card and the nth CHARACTER in the
string. Such a string is called a TEXT-value and it is housed in a
referenced TEXT-object.
-------------------------------------------
T--->! THIS TEXT VALUE LIES IN A TEXT OBJECT. !
-------------------------------------------
With TEXTs we have thus a combination of both reference (to the
housing object) and value (the string of CHARACTERS) properties.
TEXTs resemble objects (of classes) in that they posses attributes
which are accessed by the normal remote accessing (dot notation)
technique, but TEXTs and their attributes are wholly system defined.
Whereas a CHARACTER ARRAY is oriented towards accessing single
characters by direct means (subscripts), the TEXT concept is oriented
towards groupings of characters and sequentially accessing these
groups.
TEXT variables are declared in the usual fashion.
e.g. TEXT R,S,T
and the initial value of each of these variables is NOTEXT, that is
the empty string.
TEXT variables are capable of referencing TEXT objects, which may be
created by two system defined PROCEDURES - BLANKS and COPY:
T :- BLANKS(N)
creates a TEXT object of length N characters, each initialised to the
blank character. After creation of the object, its reference value is
assigned to T.
S :- COPY("SIMULA");
R :- COPY(S)
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 221
CHAPTER 3.4
COPY will accept either a TEXT value or a TEXT reference expression as
parameter, creates a TEXT object with value identical to that of the
actual parameter and of the same length, and returns a reference to
it. The result of the last two statements may be pictured by
----------------- ----------
S .---->! 1 ! 1 ! 6 ! .-!--->! SIMULA !
----------------- ----------
----------------- ----------
R .---->! 1 ! 1 ! 6 ! .-!--->! SIMULA !
----------------- ----------
magic box
Each TEXT variable has its own "magic box" which gives information
about the start position (SP), length (LG) and current position (CP)
of the object it currently references. The box also contains the
reference value of the object itself. The formal pattern of these
magic boxes is:
--------------------------
! SP ! CP ! LG ! ref.val !
--------------------------
A TEXT object may be referenced in subfields by use of the procedure
SUB
After T :- COPY("SIMULA")
then S :- T.SUB(5,2)
results in
----------------- ----------
T .---->! 1 ! 1 ! 6 ! .-!--->! SIMULA !
----------------- ----------
^
----------------- !
S .---->! 5 ! 1 ! 2 ! .-!-----------
-----------------
S references the subfield of T beginning from character 5 and of
length 2.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 222
CHAPTER 3.4
The characters may be accessed one at a time by calls on GETCHAR which
returns the value of the current character and increments the CP by
one.
After C := T.GETCHAR;
D := T.GETCHAR
the snapshot is
----------------- ----------
T .---->! 1 ! 3 ! 6 ! .-!--->! SIMULA !
----------------- ----------
^
!
----------------- !
S .---->! 5 ! 1 ! 2 ! .-!------------
-----------------
and the values of C and D are 'S' and 'I' respectively. As access was
made through T, only its CP has been incremented (twice). The reverse
process of inserting a character value into the current position is
achieved through use of PUTCHAR, which also increments the CP.
After S.PUTCHAR('6);
S.PUTCHAR('7)
the snapshot is
----------------- ----------
T .---->! 1 ! 3 ! 6 ! .-!--->! SIMU67 !
----------------- ----------
^
!
----------------- !
S .---->! 5 ! 3 ! 2 ! .-!-----------
-----------------
Note that the value of T has been changed. The CP of S is now out of
range. A further call
S.PUTCHAR
or S.GETCHAR
will result in a run time error. To provide a check, a BOOLEAN
PROCEDURE MORE is provided which returns FALSE if the CP is out of
range and TRUE otherwise. Currently,
T.MORE = TRUE S.MORE = FALSE
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 223
CHAPTER 3.4
Other useful system defined procedures are:
LENGTH which returns the length of the currently
referenced value
(T.LENGTH = 6
S.LENGTH = 2)
POS which returns the value of the CP
(T.POS = 3
S.POS = 3)
SETPOS which resets the CP. (To reset the CP's of
T and S back to their initial character, we write
T.SETPOS(1)
S.SETPOS(1) )
Text values may be transferred from one subject to another by
S := T
or a value into an object by
S := "TEXT VALUE"
Both are left justified.
The only restriction is that the TEXT object receiving the value must
be long enough to accept the value or else a run time error occurs.
Any positions not directly copied into are filled with blanks.
Several editing and de-editing procedures are defined within SIMULA.
These convert numbers to external form and vice versa. They are
designed to operate repetitively across a field and are thus oriented
towards formatted output and input.
The further detailed description of the TEXT handling facilities is
given under the sub-sections
LENGTH and MAIN
subtexts
character access
text generation
TEXT assignment
TEXT editing
Throughout these subsections X, Y, Z denote TEXT references.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 224
CHAPTER 3.4
LENGTH and MAIN
---------------
INTEGER PROCEDURE LENGTH;
-------------------------
The value of X.LENGTH is the number of CHARACTERS in the TEXT object
referenced by X.
e.g. after X :- BLANKS(10), then X.LENGTH = 10
if Y == NOTEXT, then Y.LENGTH = 0
TEXT PROCEDURE MAIN;
--------------------
X.MAIN is a reference to the TEXT object which is or contains the text
value referenced by X.
e.g. after X :- BLANKS(20);
Y :- X.SUB(1,10);
Z :- NOTEXT;
then X.MAIN == X
Y.MAIN == X
Z.MAIN == NOTEXT
The following relations hold for any TEXT reference X
X.MAIN.LENGTH >= X.LENGTH
X.MAIN.MAIN == X.MAIN
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 225
CHAPTER 3.4
SUBTEXTS
--------
TEXT PROCEDURE SUB(I,N); INTEGER I,N;
--------------------------------------
The call
X.SUB(J,M)
designates that part of the TEXT object referneced by X starting in
CHARACTER position J and of length M characters.
e.g. after X :- COPY("MAIN NOT SUB-TEXT");
T :- X.SUB(10,8);
then T = "SUB-TEXT"
For X.SUB(J,M) to be a legal call, the subtext must be included in X.
Thus
J > 0
J + M-1 <= X.LENGTH
If these conditions do not hold a run time error results.
TEXT PROCEDURE STRIP;
---------------------
STRIP is used to return a reference to a subfield of a TEXT object
which differs from the original in that all blanks on the right are
ignored. X.STRIP is thus equivalent to X.SUB(1,N) where the remaining
CHARACTERS of X (from position N+1 and of length X.LENGTH-N), if any,
are all blanks.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 226
CHAPTER 3.4
CHARACTER access
----------------
The CHARACTERS, values housed in a TEXT object, are accessible one at
a time. Any TEXT reference contains a "position indicator" which
identifies the currently accessible CHARACTER of the referenced TEXT
object.
The position indicator of NOTEXT is 1. A TEXT reference obtained by
calling any system defined TEXT procedure has its position indicator
set to 1. The position indicator of a given TEXT reference may be
altered by the PROCEDURES SETPOS, GETCHAR, PUTCHAR,
TEXT-reference-assignment and any editing or de-editing PROCEDURE.
Position indicators are left unaltered by TEXT reference relations,
TEXT value relations and TEXT value assignments.
INTEGER PROCEDURE POS;
----------------------
X.POS is the current value of the position indicator of X. The
following relation is always TRUE.
1 <= X.POS <= X.LENGTH + 1
PROCEDURE SETPOS(I); INTEGER I;
--------------------------------
The effect of X.SETPOS(M) is to assign the value of M to the position
indicator of X, if 1 <= m <= X.LENGTH +1. If M is out of this range,
then the value X.LENGTH + 1 is assigned.
BOOLEAN PROCEDURE MORE;
-----------------------
X.MORE is TRUE if the position indicator of X is in the range 1
through X.LENGTH, otherwise the value is FALSE.
CHARACTER PROCEDURE GETCHAR;
----------------------------
The value of X.GETCHAR is a copy of the currently accessible CHARACTER
of X provided X.MORE is TRUE. In addition, the position indicator of
X is then increased by one. A run time error results if X.MORE was
FALSE.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 227
CHAPTER 3.4
PROCEDURE PUTCHAR(C); CHARACTER C;
----------------------------------
The effect of X.PUTCHAR(C) is to replace the currently accessible
CHARACTER of X by the value of C provided that X.MORE is TRUE. In
addition the position indicator of X is then increased by one. If
X.MORE is FALSE, a run time error results.
Example:
--------
The PROCEDURE COMPRESS rearranges the CHARACTERS of the TEXT object
referenced by the actual parameter by collecting non-blank CHARACTERS
in the leftmost part of the TEXT object and filling in the remainder,
if any, with blanks. Since the parameter is called by reference (and
not by name), its position indicator is unaltered.
PROCEDURE COMPRESS(T); TEXT T;
BEGIN TEXT U; CHARACTER C;
T.SETPOS(1); U :- T;
MOVELEFT: WHILE U.MORE DO
BEGIN C := U.GETCHAR;
IF C NE ' ' THEN T.PUTCHAR(C);
END;
COMMENT ***WE NOW FILL IN THE RIGHT WITH
BLANKS*** ;
T.SUB(T.POS,T.LENGTH-T.POS+1) := NOTEXT;
END ***COMPRESS***
Note the use of a value assignment to T.SUB, and the use of NOTEXT on
a right hand side as a neat way of filling a TEXT value to blanks.
After X :- COPY("GET RID OF ALL BLANKS");
COMPRESS(X);
THEN X = "GETRIDOFALLBLANKS "
X.STRIP = "GETRIDOFALLBLANKS"
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 228
CHAPTER 3.4
TEXT generation
---------------
N.B. Procedures BLANKS and COPY are non-local.
TEXT PROCEDURE BLANKS(N); INTEGER N;
------------------------------------
The reference value is a new TEXT object of length N, filled with
blank CHARACTERS.
The value of the actual parameter, M, is restricted to
0 <= M <= 2^18-1 = 262143
otherwise a run time error results.
TEXT PROCEDURE COPY(T); VALUE T; TEXT T;
----------------------------------------
The referenced value is a new TEXT object which is a copy of the TEXT
value which is (or is referenced by) the actual parameter.
Example:
--------
T :- COPY("DEC10SIMULA");
is equivalent to,
T :- BLANKS(11);
T := "DEC10SIMULA";
There is no explicit statement in SIMULA to delete or destroy TEXTs.
TEXTs are automatically removed by the garbage collector when there is
no way to refer to the TEXT any more from the program. Note that as
long as there is a way to refer from the program to any subtext
(except NOTEXT), the whole main TEXT is kept in core (and available
through the procedure MAIN).
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 229
CHAPTER 3.4
TEXT assignment
---------------
a) TEXT-reference-assignment
-------------------------
A TEXT-reference-assignment causes a copy of the TEXT-reference (i.e.
the magic box values) obtained by evaluating the right part to be
assigned to the left part variable - this includes a copy of its
position indicator.
e.g. after X :- COPY("ABCD");
X.SETPOS(3);
Y :- X;
then X.POS = 3
Y.POS = 3
In general, after X :- P; where P is a TEXT reference,
then X == P
X = P
X.POS = P.POS
are all TRUE.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 230
CHAPTER 3.4
b) TEXT-value-assignment
---------------------
Consider the value assignment
T := P;
let the length of T be Ll, and the right part be a TEXT value of
length Lr. There are three cases to consider:
Ll = Lr: the character contents of the right part TEXT are
copied to the left part TEXT
Ll > Lr: the character contents of the right part are
copied into the leftmost Lr characters of the left
part TEXT, whose remaining Ll-Lr CHARACTERS are
filled with blanks.
Ll < Lr: a run time error results.
The POS of T (and P) will not be changed.
After T :- COPY("EIGHT CHARS");
T := "WRONG:11";
then T = "WRONG:11 "
Note that
T := NOTEXT;
is an efficient way to set all the character positions of T to blanks.
In a multiple TEXT value assignment (TA is a TEXT ARRAY)
T[1] := T[2] := ..... T[N] := P;
then
TA[J].LENGTH >= TA[J+1].LENGTH
for J = 1,2,...,N-1 must be true.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 231
CHAPTER 3.4
Variable length TEXTs and TEXT concatenation.
--------------------------------------------
There are two ways in which you can achieve variable length TEXTs in
SIMULA. You can either have variable length TEXTs with a fixed upper
length limit (like VARYING in PL/I), or with no upper limit.
In the first case, you allocate a main text with the upper length
limit as its length. You can then use subtexts when you want shorter
texts, and you can change length by
T:- T.MAIN.SUB(1,NEWLENGTH)
If you want no fixed upper limit (except the system limit 262143), you
can allocate new texts with the procedure BLANKS, e.g. "t:-
BLANKS(newlength)". A concatenation procedure would then for example
copy the parts into subtexts of t by
t.SUB(1,PART1.LENGTH):= PART1;
T.SUB(PART1.LENGTH+1,PART2.LENGTH):= PART2;
(A concatenation procedure will be available in the SIMULA program
library. See part III of the DECsystem-10 SIMULA Handbook.)
If you want linking of character strings without copying, you can
easily implement this yourself in SIMULA using e.g. SIMSET.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 232
CHAPTER 3.4
Text editing and de-editing
---------------------------
TEXT editing and de-editing procedures are provided to transform
binary values into text strings and vice versa. The syntax for
numeric-text-values (external data) follows:
numeric-text-value
------------------
** **
* grouped-item *
** real-item **
* integer-item *
** **
grouped-item
------------
sign-part[[groups].]groups
groups
------
[digits blank]... digits
real-item
---------
** **
* [[digits].]digits[E sign-part digits] *
sign-part ** **
* E sign-part digits *
** **
integer-item
------------
sign-part digits
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 233
CHAPTER 3.4
sign-part
---------
[blank]... [+-] [blank]...
where 'E' represents an exponent sign. This CHARACTER may be altered
by the user by use of the PROCEDURE LOWTEN (see Appendix B).
A numeric-text-value is a character sequence subject to the above
rules.
De-editing procedures
---------------------
A de-editing procedure operating on a given TEXT reference X operates
in the following way:
1) The longest numeric item of the given form is located, contained
within X and containing the first character of X. If no such item
can be found, a run time error results. Note that - unlike
GETCHAR - GETINT, GETREAL and GETFRAC always starts from the
beginning of the text!
2) The numeric item is interpreted as a number. If it is outside the
accepted range (see CHAPTER 2, section 2.5.1) a run time error
results.
3) The position indicator of X is made one greater than the last
character of the numeric item.
****************************************************************
* N.B. Unless otherwise stated, the de-editing procedures are *
* illustrated in the context: *
* *
* T :- COPY("1234.5+7.3E4AB"); *
* S :- T.SUB(7,6); *
* R :- T.SUB(5,2); *
****************************************************************
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 234
CHAPTER 3.4
INTEGER PROCEDURE GETINT;
-------------------------
Locates an integer-item.
T.GETINT = 1234
S.GETINT = 7
R.GETINT causes a run time error
LONG REAL PROCEDURE GETREAL;
----------------------------
locates a real-item
T.GETREAL = 1234.5
S.GETREAL = 73000.0
R.GETREAL = 0.5
INTEGER PROCEDURE GETFRAC;
--------------------------
Locates a grouped item. In its interpretation, any number of single
blanks and one decimal point are ignored and the resulting value is an
INTEGER.
After T := COPY(1 013.42");
then T.GETFRAC = 101342
Editing procedures
------------------
Editing procedures in a given text reference X convert arithmetic
values to numeric items. After an editing operation, the numeric item
obtained is right adjusted in the TEXT X preceded by padding blanks.
The final value of the position indicator is X.LENGTH+1.
A positive number is edited with no sign. If X == NOTEXT then a run
time error results, otherwise if X is too short to contain the numeric
item, an edit overflow is caused (X is filled with asterisks) and a
warning message is given at the end of program execution.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 235
CHAPTER 3.4
PROCEDURE PUTINT(I); INTEGER I;
-------------------------------
T.PUTINT(VAL) converts the value of the parameter to an integer item
of the designated value.
For T.LENGTH = 10:
T.PUTINT(-37) -37
T.PUTINT(118.8) 119
PROCEDURE PUTFIX(R,N); [LONG] REAL R; INTEGER N;
------------------------------------------------
T.PUTFIX(VAL,M) results in an integer-item if M=0, or a real-item
(with no exponent) if M>1 with M digits after the decimal point. It
designates a number equal in value to VAL rounded to M decimal places.
A run time error results if M<0.
T.PUTFIX(18,0) 18
T.PUTFIX(-1375.4,3) -1375.400
PROCEDURE PUTREAL(R,N); [LONG] REAL R; INTEGER N;
-------------------------------------------------
T.PUTREAL(VAL,M) results in a real-item to M significant places with
an exponent
X.XXXXXXXXE+-XX
M figures
If M<0, a run time error results
If M=0, the exponent is preceded by a sign-part
If M=1, the exponent is preceded by an integer-item of one digit.
For T.LENGTH = 10:
T.PUTREAL(16,0) E+01
T.PUTREAL(-25.32,1) -3E+01
T.PUTREAL(-0.001472,3) -1.47E-03
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 236
CHAPTER 3.4
PROCEDURE PUTFRAC(I,N); INTEGER I,N;
-------------------------------------
T.PUTFRAC(VAL,M) results in a grouped-item
XXX XXX.XXX XXX
If M=0, there is no decimal point. If M>0, there are M digits after
the decimal point. Each digit group consists of 3 digits except
possibly the first and the last. The numeric item is an exact
representation of VAL*10(-M).
T.PUTFRAC(10012416,3) 10 012.416
The editing and de-editing procedures are oriented towards "fixed
field" text manipulation.
Example:
--------
TEXT TR,TYPE,AMOUNT,PRICE,PAYMENT;
INTEGER PAY,TOTAL;
TR :- BLANKS(80);
TYPE :- TR.SUB(1,5);
AMOUNT :- TR.SUB(20,5);
PRICE :- TR.SUB(30,6);
PAYMENT :- TR.SUB(60,10);
..........
IF TYPE = "ORDER" THEN
BEGIN PAY := AMOUNT.GETINT*PRICE.GETFRAC;
TOTAL := TOTAL + PAY;
PAYMENT.PUTFRAC(PAY,2);
END;
..........
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 237
CHAPTER 3.5
3.5 THE SYSTEM CLASS BASICIO
------------------------
Files or data sets are collections of data external to a program.
They may be organised in a sequential manner (a batch of cards) or
direct access manner (collection of items on a disc where each item is
specified directly).
A file is composed of several records each of which is an ordered
sequence of CHARACTERS.
The internal representation of a record is naturally held in a TEXT
object, but TEXT handling facilities alone are not enough for treating
input and output to secondary storage. We need in addition
a) means for tying the external medium to the internal
representation,
b) for transferring information (record-by-record) either from the
external file or to the external file, and
c) either interpreting the information in the internal TEXT object in
a sequential manner, or else filling the TEXT object in a
sequential manner.
A SIMULA system provides system classes for these purposes. The
system classes have the hierarchy
-------file---------
! ! !
INFILE OUTFILE DIRECTFILE
!
PRINTFILE
The identifier "file" is not accessible by the user - it defines the
parts common to the subclasses.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 238
CHAPTER 3.5
The four types of defined file are:
INFILE a sequential input file which transfers data from an
external file to the program
OUTFILE a sequential output file which transfers data from the
program to an external file
PRINTFILE (a subclass of OUTFILE) a sequential file with special
extra facilities for transmitting information to a line
printer or conversational terminal
DIRECTFILE a direct file with facilities for input and output
Each file object has a TEXT parameter called "name", which is not
accessible by the user after creation of the file object. When the
file object is created, this parameter specifies (possibly together
with a specification file) the device, filename etc. Example:
"IN DTA0: X.Y" or "OUT DSK: X.Q". For further information see the
DECsystem-10 SIMULA Language Handbook part II.
The CLASS file has the declaration:
CLASS file(name); VALUE name; TEXT name;
VIRTUAL : PROCEDURE OPEN, CLOSE;
BEGIN TEXT IMAGE; BOOLEAN opened;
PROCEDURE SETPOS(I); INTEGER I;
IMAGE.SETPOS(I);
INTEGER PROCEDURE POS;
POS := IMAGE.POS;
BOOLEAN PROCEDURE MORE;
MORE := IMAGE.MORE;
INTEGER PROCEDURE LENGTH;
LENGTH := IMAGE.LENGTH;
END ***file***
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 239
CHAPTER 3.5
The variable IMAGE references a TEXT object value which acts as a
buffer containing the information currently being processed.
The PROCEDURES SETPOS, POS, MORE and LENGTH defined local to file
operate on the buffer IMAGE. Given a reference X to an object
belonging to a subclass of file, then it is now possible to write the
more convenient
X.MORE X.LENGTH ..........
Instead of (the still valid)
X.IMAGE.MORE X.IMAGE.LENGTH ..........
The PROCEDURES OPEN and CLOSE, which are specified as VIRTUAL but have
no matching declaration at the "file" level, complete the definition
of CLASS file. The matching PROCEDURES declared in the subclasses of
"file" conform to the patterns below with possible minor variations
depending upon the subclass. The variations are listed in the
appropriate following sub-sections.
The PROCEDURE outlines are:
PROCEDURE OPEN(BUF); TEXT BUF;
BEGIN IF opened THEN error;
IMAGE :- BUF; opened := TRUE;
END;
PROCEDURE CLOSE;
BEGIN ..........
IMAGE :- NOTEXT; opened := FALSE;
END
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 240
CHAPTER 3.5
No information can be processed through a "file" object until it has
not only been generated but also opened. This can only be achieved by
a call on the PROCEDURE OPEN whose actual parameter is assigned to
IMAGE and acts as the buffer. A call on OPEN when a "file" is already
open gives a run time error.
The PROCEDURE CLOSE closes a file and releases the buffer (by the
assignment IMAGE :- NOTEXT). No information may be transmitted
through a closed "file" object, but it may be opened again by a
further call on OPEN.
CLASS INFILE
------------
file CLASS INFILE; VIRTUAL : PROCEDURE INIMAGE;
BOOLEAN PROCEDURE ENDFILE;
BEGIN PROCEDURE OPEN(BUF); TEXT BUF;.....;
PROCEDURE CLOSE;......;
BOOLEAN PROCEDURE ENDFILE;.........;
CHARACTER PROCEDURE INCHAR;........;
BOOLEAN PROCEDURE LASTITEM;........;
INTEGER PROCEDURE ININT;...........;
REAL PROCEDURE INREAL;.............;
INTEGER PROCEDURE INFRAC;..........;
TEXT PROCEDURE INTEXT(W); INTEGER W;......;
END ***INFILE***
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 241
CHAPTER 3.5
PROCEDURE OPEN
--------------
conforms to the pattern listed with CLASS file but in addition
positions the current position indicator to "LENGTH+1".
PROCEDURE CLOSE
---------------
conforms to the pattern listed with CLASS file.
PROCEDURE ENDFILE
-----------------
returns TRUE before the INFILE is opened (by OPEN), if the end of
external file marker has been met, and if the INFILE has been closed
(by a call on CLOSE).
PROCEDURE INIMAGE
-----------------
transfers an external file record into the TEXT IMAGE. A run time
error will occur if the TEXT object referenced by IMAGE is too short
to contain the record. If the record is shorter than IMAGE, is is
left adjusted and the remainder of IMAGE is filled with blanks.
Finally the position indicator of IMAGE is set to 1. When the last
record has been read in, and INIMAGE is called again, a call of
ENDFILE will return TRUE. Any further call on INIMAGE, INCHAR,
INTEXT, ININT, INREAL or INFRAC will result in a run time error.
BOOLEAN PROCEDURE LASTITEM;
---------------------------
returns FALSE only if the external file contains more information
(non-blank CHARACTERS). It scans past all blank CHARACTERS and
horizontal tabs (calling INIMAGE if need be). If LASTITEM returns
FALSE then the currently accessible CHARACTER of IMAGE is the first
non-blank CHARACTER. If ENDFILE returns TRUE, a call on LASTITEM also
returns TRUE.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 242
CHAPTER 3.5
CHARACTER PROCEDURE INCHAR;
---------------------------
gives access to the next available CHARACTER and scans past it. If
IMAGE.MORE is FALSE, then INIMAGE is called once and the value of the
call is the first CHARACTER of the new image. INCHAR gives a run time
error if an attempt is made to read past the last record in the file.
TEXT PROCEDURE INTEXT(W); INTEGER W;
------------------------------------
INTEXT(M) creates a copy of the next M CHARACTERS (which may be spread
over several records) and returns a reference to this copy. If M < 0
or M > 2^18-1 then a run time error results. A run time error will
also result if the file does not contain M more CHARACTERS, i.e. an
attempt is made to read past the last record.
The remaining PROCEDURES treat the file as a continuous stream of
records. They scan past any number of blanks and horizontal tabs
(calling INIMAGE if need be) and then de-edit a numeric item lying in
one image. This is done by calling LASTITEM (which scans past the
blanks and tabs) and then referencing the remainder of the current
IMAGE by a temporary TEXT variable, say T. The value of the
"IN***"-PROCEDURE call is the value of the corresponding call on
T."GET***". On exit, the current position indicator is updated to
reference past the de-edited field, i.e. to reference the first
CHARACTER which is not a part of the de-edited numeric item.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 243
CHAPTER 3.5
e.g.
T
/ \
!<----------------- ----------------->!
------------------------------------------------- intermediate
! ..... ! ! ! 1 ! 2 ! 3 ! . ! 5 ! A ! ..... ! <---IMAGE
------------------------------------------------- step
^
!
current
position
indicator
T.GETINT = 123
--------------------------------------------------
! ...... ! ! ! 1 ! 2 ! 3 ! . ! 5 ! A ! ..... !
--------------------------------------------------
^
!
current
position
indicator
ININT = 123
Run time errors will result if the remaining CHARACTERS in the file
are blanks (LASTITEM = TRUE) or if the item is not numeric.
An outline of ININT is:
INTEGER PROCEDURE ININT;
BEGIN TEXT T; IF LASTITEM THEN ERROR;
T :- IMAGE.SUB(POS,LENGTH-POS+1);
ININT := T.GETINT;
SETPOS(POS+T.POS-1);
END ***ININT***
INREAL and INFRAC follow the same pattern.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 244
CHAPTER 3.5
CLASS OUTFILE
-------------
file CLASS OUTFILE; VIRTUAL : PROCEDURE OUTIMAGE;
BEGIN PROCEDURE OPEN(BUF); TEXT BUF;....;
PROCEDURE CLOSE;..................;
PROCEDURE OUTIMAGE;...............;
PROCEDURE OUTINT(I,W); INTEGER I,W;.....................;
PROCEDURE OUTFIX(R,N,W); [LONG] REAL R; INTEGER N,W;....;
PROCEDURE OUTREAL(R,N,W); [LONG] REAL R; INTEGER N,W;...;
PROCEDURE OUTFRAC(I,N,W); INTEGER I,N,W;................;
PROCEDURE OUTTEXT(T); VALUE T; TEXT T;..................;
PROCEDURE OUTCHAR(C); CHARACTER C;......................;
END ***OUTFILE***
PROCEDURE OPEN(BUF); TEXT BUF;
------------------------------
Follows the pattern set by the PROCEDURE OPEN listed with CLASS file.
PROCEDURE CLOSE;
----------------
Conforms to the pattern set by the PROCEDURE CLOSE listed with CLASS
file but in addition checks the value of POS. If POS > 1 then
presumably extra information has been copied into IMAGE since the last
call on OUTIMAGE.
Accordingly, if POS > 1, OUTIMAGE will be called once before the
OUTFILE is closed.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 245
CHAPTER 3.5
PROCEDURE OUTIMAGE;
-------------------
OUTIMAGE transfers the contents of IMAGE to the external file creating
a copy as a new record. IMAGE is then cleared to blanks and its
current position indicator set to one.
PROCEDURE BREAKOUTIMAGE;
------------------------
BREAKOUTIMAGE works exactly as OUTIMAGE with the only difference that
no carriage return-linefeed is output at the end of the line. Thus,
the IMAGE is cleared in the same way as for OUTIMAGE. BREAKOUTIMAGE
is useful when writing conversational programs, to ask a question and
get the answer on the same line. Note that BREAKOUTIMAGE will output
any trailing blanks of the image up to POS, while OUTIMAGE will always
strip off these blanks.
PROCEDURE OUTTEXT(T); VALUE T; TEXT T;
----------------------------------------
A copy of the CHARACTER sequence represented by the actual parameter
is edited into IMAGE from the current position. If the remaining
length of IMAGE is insufficient, OUTIMAGE is called and output will
start at the first position of a fresh image. if T.LENGTH is greater
than IMAGE.LENGTH then a run time error will occur.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 246
CHAPTER 3.5
PROCEDURE OUTCHAR(C); CHARACTER C;
----------------------------------
Outputs the value of C into the current position of IMAGE (if
MORE = FALSE, then OUTIMAGE is called first). In either case, the
current position indicator is then incremented.
The remaining PROCEDURES are all based upon the PUT-PROCEDURES local
to TEXTs. The corresponding OUT-PROCEDURES are augmented by an extra
parameter W which specifies the field width.
-------------------------------------
!/////////! ! ! !
IMAGE .----->!/////////! ! ! !
!/////////! ! ^ ! !
-----------------------!-------------
!
! ! ! ! !
--------- --------- !
!
Final position of current
portion FIELD position indicator
of IMAGE
already
filled
The editing PROCEDURE commences by establishing a temporary TEXT
reference (FIELD) to the next sequence of W CHARACTERS lying in one
IMAGE. If the current IMAGE has not enough space left, OUTIMAGE is
called. Then the value is edited by calling FIELD."PUT***" where
"PUT***" is the PUT-PROCEDURE corresponding to the OUT-PROCEDURE.
Finally the current position indicator is increased by W to reference
- past the just-edited field.
PROCEDURE OUTINT(I,W); INTEGER I,W;
FIELD(W).PUTINT(I);
PROCEDURE OUTFRAC(I,N,W); INTEGER I,N,W;
FIELD(W).PUTFRAC(I,N);
PROCEDURE OUTREAL(P,N,W); [LONG] REAL P; INTEGER N,W;
FIELD(W).PUTREAL(P,N);
PROCEDURE OUTFIX(P,M,W); [LONG] REAL P; INTEGER M,W;
FIELD(W).PUTFIX(P,M);
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 247
CHAPTER 3.5
CLASS PRINTFILE
---------------
OUTFILE CLASS PRINTFILE;
BEGIN PROCEDURE OPEN(BUF); TEXT BUF;...............;
PROCEDURE CLOSE;.....;
PROCEDURE LINESPERPAGE(N); INTEGER N;........;
INTEGER PROCEDURE LINE(N); INTEGER N;........;
PROCEDURE SPACING(N); INTEGER N;.............;
PROCEDURE EJECT(N); INTEGER N;...............;
PROCEDURE OUTIMAGE;..........................;
END ***PRINTFILE***
CLASS PRINTFILE further orients the prefixing CLASS OUTFILE towards
conversational terminal (TTY:) or line printer output. The PROCEDURES
OPEN and CLOSE take the pattern of those local to OUTFILE but in
addition OPEN positions to the top of the next page.
PROCEDURE LINESPERPAGE(N); INTEGER N;
-------------------------------------
Initially the number of printable lines per page is fixed at some
value (V) dependent upon the installation. A call LINESPERPAGE(M)
will alter this figure to allow only M printable lines per page. If M
= -1 then no automatic page skips will occur. This is recommended for
display terminal output.
PROCEDURE SPACING(N); INTEGER N;
--------------------------------
Initially the spacing is 1 and successive images are printed on
successive lines. A call SPACING(M) will alter this to separate
successive lines by M-1 blank lines. This becomes effective after the
next call on OUTIMAGE. If M > "current value of lines per page", or M
< 0, then a run time error results. If M = 0, overprinting will occur
- successive images being printed on the same physical line.
PROCEDURE EJECT(N); INTEGER N;
------------------------------
This PROCEDURE skips to a certain line on the page - (it avoids
calling OUTIMAGE several times). EJECT(L) will position to line on
this page if this is further down the current page (if L > LINE), or
else skip to LINE L of the next page if L <= LINE.
A run time error occurs if L <= 0. If L > LINESPERPAGE, EJECT(L) is
equivalent to EJECT(1).
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 248
CHAPTER 3.5
INTEGER PROCEDURE LINE;
-----------------------
This PROCEDURE returns the INTEGER value of the line number which
indicates the next line to be printed. Thus EJECT(LINE+3) will skip
three lines and not alter spacing. After each call on OUTIMAGE, the
line number is incremented by the current spacing.
PROCEDURE OUTIMAGE;
-------------------
This PROCEDURE acts like the OUTIMAGE of OUTFILE but in addition
increments the line number by spacing, and will position to the top of
the next page if the current page is filled.
Example:
--------
This example shows the use of three types of file and how to open and
close them. The example was chosen to demonstrate these features and
how formatting is available by use of the sub-text concept. The logic
of the example is particularly simple. A file of transactions has
been punched on cards in the format
col 1-5 customer number CNO
col 7-16 sum of debit transactions DB
col 19-28 sum of credit transactions CR
Each transaction is on a fresh card. The information is to be
compressed and recorded on a new sequential file on tape. The length
of each tape record is 15 CHARACTERS, and its format is:
5 10
*************************
* CNR * CR - DB *
*************************
customer total sum of
number transactions
Checks are made that the customer number is valid (1-3-7 digit check)
and that the card is validly punched. If not, a copy of the card is
printed on a line printer, and the scan continues.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 249
CHAPTER 3.5
Note that the INFILE and PRINTFILE share the same buffer.
*******
* *
-----* CARDS *
! * *
! *********
!
!
***********************************************
* * *
BUFFER * * CUSTOMER *
* * *
***********************************************
! !
! !
-------- --------
! !
! !
*********** ***********
* * * *
NCUSTOMER. * * * PRINTER *
IMAGE * * * *
*********** * * * * *
! * * * *
!
------
!
!
******
* *
* TAPE *
* *
******
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 250
CHAPTER 3.5
BEGIN
EXTERNAL INTEGER PROCEDURE checkint;
TEXT cnr, db, cr, nr, t1, t2, t3, t4, kt, tsum,
ts, buffer, err;
INTEGER sum, balance;
REF(Infile) customercards;
REF(Printfile) print;
REF(Outfile) ncustomer;
BOOLEAN PROCEDURE nonnumeric(t); TEXT t;
COMMENT ***THIS PROCEDURE RETURNS TRUE IF THE TEXT
PARAMETER CAN NOT BE NUMERICALLY INTER-
PRETED FROM THE LEFT*** ;
BEGIN
t.Setpos(1);
nonnumeric:= checkint(t) NE 1;
END;
buffer :- Blanks(132);
COMMENT ***CONSTRUCT THE CARDFILE*** ;
customercards :- NEW Infile("CCARD DSK: CCARD.CDR");
customercards.Open(buffer.Sub(10,80));
cnr :- buffer.Sub(10,5);
nr :- cnr.Sub(1,4);
t1 :- nr.Sub(1,1);
t2 :- nr.Sub(2,1);
t3 :- nr.Sub(3,1);
t4 :- nr.Sub(4,1);
kt :- cnr.Sub(5,1);
db :- buffer.Sub(16,10);
cr :- buffer.Sub(28,10);
COMMENT ***CONSTRUCT PRINTFILE*** ;
print :- NEW Printfile("PRINT LPT:");
print.Open(buffer);
err:- buffer.Sub(1,6);
COMMENT ***CONSTRUCT TAPEFILE*** ;
ncustomer :- NEW Outfile("NCUSTOMER MTA:");
ncustomer.Open(Blanks(15));
COMMENT ***CONSTRUCT WORKING TEXT TSUM*** ;
tsum :- Blanks(3);
ts :- tsum.Sub(3,1);
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 251
CHAPTER 3.5
INSPECT ncustomer DO
BEGIN
customercards.Inimage;
WHILE NOT customercards.Endfile DO
BEGIN IF nonnumeric(cnr) OR
nonnumeric(db) OR
nonnumeric(cr)
THEN error:
BEGIN err:= "ERROR"; print.Outimage
END ELSE
BEGIN COMMENT ***137 DIGIT CHECK*** ;
sum := 7*(t1.Getint + t4.Getint) +
3*t3.Getint + t2.Getint;
tsum.Putint(sum);
IF ts NE kt THEN GOTO error;
COMMENT ***OUTPUT TO TAPE*** ;
balance := cr.Getint - db.Getint;
Outtext(cnr);
Outint(balance,10);
Outimage;
END;
customercards.Inimage;
END;
END ***INSPECT NCUSTOMER*** ;
slutt: customercards.Close;
ncustomer.Close;
print.Close
END
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 252
CHAPTER 3.5
CLASS DIRECTFILE
----------------
file CLASS DIRECTFILE;
VIRTUAL: PROCEDURE LOCATE, ENDFILE, INIMAGE, OUTIMAGE;
BEGIN PROCEDURE OPEN(BUF); TEXT BUF; . . . . . . . . . . . . ;
PROCEDURE CLOSE; . . . . . . . . . . . . . . . . . . . ;
INTEGER PROCEDURE LOCATION; . . . . . . . . . . . . . . ;
PROCEDURE LOCATE(I); INTEGER I; . . . . . . . . . . . . ;
BOOLEAN PROCEDURE ENDFILE; . . . . . . . . . . . . . . ;
PROCEDURE INIMAGE; . . . . . . . . . . . . . . . . . . .;
CHARACTER PROCEDURE INCHAR; . . . . . . . . . . . . . . ;
BOOLEAN PROCEDURE LASTITEM; . . . . . . . . . . . . . . ;
INTEGER PROCEDURE ININT; . . . . . . . . . . . . . . . .;
REAL PROCEDURE INREAL; . . . . . . . . . . . . . . . . .;
INTEGER PROCEDURE INFRAC; . . . . . . . . . . . . . . . ;
TEXT PROCEDURE INTEXT(W); INTEGER W; . . . . . . . . . .;
PROCEDURE OUTIMAGE; . . . . . . . . . . . . . . . . . . ;
PROCEDURE OUTCHAR(C); CHARACTER C; . . . . . . . . . . .;
PROCEDURE OUTINT(I,W); INTEGER I,W; . . . . . . . . . . ;
PROCEDURE OUTFIX(R,N,W); [LONG] REAL R; INTEGER N,W;. . ;
PROCEDURE OUTREAL(R,N,W); [LONG] REAL R; INTEGER M,W;. .;
PROCEDURE OUTFRAC(I,N,W); INTEGER I,N,W; . . . . . . . .;
PROCEDURE OUTTEXT(T); VALUE T; TEXT T; . . . . . . . . .;
END ***DIRECTFILE***
A directfile represents an external file in which individual records
are addressed by indices (ordinal numbers). The index of the current
record is returned by a call on LOCATION. The current record may be
copied into the program by a call on INIMAGE, or overwritten by a call
on OUTIMAGE. In either case, the sequentially next record is then
taken as the current record. This sequential accessing may be altered
at any time a call LOCATE(M) which will locate the Mth external record
and make it the new current record.
If M <= 0 and OUTIMAGE is called, then a run time error will occur.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 253
CHAPTER 3.5
PROCEDURE OPEN
--------------
conforms to the pattern of OPEN in CLASS file but in addition locates
the first record.
PROCEDURE CLOSE
---------------
conforms to the pattern of CLOSE in CLASS file.
PROCEDURE ENDFILE
-----------------
is FALSE if the current index locates a record in the file.
Calls on the PROCEDURE INIMAGE will cause run a time error if ENDFILE
is TRUE. Otherwise INIMAGE (and OUTIMAGE) conform to these of the
same identifiers in INFILE and OUTFILE but in addition increment the
index of the current record by one.
The remaining PROCEDURES are analogous to the corresponding PROCEDURES
of INFILE and OUTFILE.
A more complete description of DIRECTFILE is given in DECsystem-10
SIMULA Language Handbook Part II.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 254
CHAPTER 3.5
CLASS BASICIO
-------------
The system defined file facilities are grouped together in the CLASS
BASICIO whose skeleton reads:
CLASS BASICIO(sysinlength,sysoutlength);
INTEGER sysinlength,sysoutlength;
BEGIN CLASS file. . . . . . . ;
file CLASS INFILE. . . . . ;
file CLASS OUTFILE. . . . .;
file CLASS DIRECTFILE. . . .;
OUTFILE CLASS PRINTFILE. . . ;
REF(INFILE)sysin;
REF(PRINTFILE)sysout;
REF(INFILE) PROCEDURE SYSIN; SYSIN :- sysin;
REF(PRINTFILE) PROCEDURE SYSOUT; SYSOUT :- sysout;
sysin :- NEW INFILE("SYSIN");
sysin.OPEN(BLANKS(sysinlength)); See note 1)
sysout :- NEW PRINTFILE("SYSOUT");
sysout.OPEN(BLANKS(sysoutlength)); See note 1)
INNER;
sysin.CLOSE; sysout.CLOSE;
END ***BASICIO***
1) The image sizes of SYSIN and SYSOUT depend on the device. If the
device is a conversational terminal with a known linelingth, then the
image size is the linelength of the device. If the device is not a
conversational terminal or has no known linelength, then the image
size is 80 for SYSIN and 132 for SYSOUT. Note however that is is very
easy for a programmer to change this by writing e.g.
"sysin.image:-blanks(200);" or "sysout.image:-blanks(600);" in his
source program. A SIMULA program will not be able to accept longer
input or produce longer output lines on SYSIN and SYSOUT. A large
imagesize will thus allow longer lines but will give more expensive
calls to inimage and outimage.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 255
CHAPTER 3.5
BASICIO contains actions to generate an INFILE, SYSIN, and a
PRINTFILE, SYSOUT. For a conversational job, the default is that
SYSIN and SYSOUT both refer to the conversational terminal. For a
batch job, the default is that SYSIN refers to the control file,
SYSOUT to the batch job log. This can be changed by the programmer,
e.g. to make SYSIN refer to a disk file, a card reader or a magnetic
tape and to make SYSOUT refer to a disk file or the line printer. For
more information about this, see the DECsystem-10 SIMULA Language
Handbook part II.
SYSIN and SYSOUT are accessible only through PROCEDURES which copy the
values of certain identifiers (sysin, sysout) which are otherwise not
accessible by the user.
A user's program behaves as though it is enclosed as follows:
BASICIO(80,80)
BEGIN INSPECT SYSIN DO
INSPECT SYSOUT DO
<program>
END;
When a user program begins the system automatically generates two
files - one INFILE for input referenced by SYSIN, and one for output
referenced by SYSOUT.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 256
CHAPTER 3.5
SYSIN .--- ----------INIMAGE-----
! ! !
V V !
----------- ------------ !
! IMAGE .-!------->! ! !
! ININT ! ------------ !
! INREAL ! !
! INTEXT ! !
! INIMAGE ! !
----------- -------------
! !
! ------- !
! ! ! !
conversational ! ! ! !
terminal ! ! ! !
! ! ! !
! ------- !
! !
-------------
^
!
!
SYSOUT .--- !
! !
V !
------------- ---------------
! IMAGE .---!----------->! ! !
! OUTINT ! --------------- !
! OUTREAL ! ! !
! OUTTEXT ! ! !
! OUTIMAGE ! ----OUTIMAGE-----
! EJECT !
! . .. .. . !
-------------
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 257
CHAPTER 3.5
When the actions of the user defined program are exhausted, control
returns to the prefix level of the BASICIO object and continues after
the INNER. The following two statements close the two system
generated files.
The inspect statements enclosing the program allow the user to write
ININT, INIMAGE,..... instead of SYSIN.ININT, SYSIN.INIMAGE and
OUTREAL, OUTIMAGE,.... instead of SYSOUT.OUTREAL, SYSOUT.OUTIMAGE.
There are attribute name clashes
OPEN which should never be used for
CLOSE SYSIN or SYSOUT
IMAGE
SETPOS
POS
MORE
LENGTH
When these occur they are naturally bound to SYSOUT and the
corresponding attributes of SYSIN may be obtained by writing
SYSIN.SETPOS, SYSIN.IMAGE et. Alternatively, an input section may be
written as
INSPECT SYSIN DO
BEGIN
input - in this block occurrences IMAGE,
SETPOS, POS, MORE and length are bound to SYSIN
END;
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 258
CHAPTER 4
CHAPTER 4: SEPARATE COMPILATION
-------------------------------
4.1 Why separate compilation?
-------------------------
There are basically two reasons for separate compilation:
1) When several programmers are working on a large program product,
then there is a need for dividing that large program product into
modules so that:
a) These modules can be compiled and tested separately.
b) There is a defined interface between the modules and automatic
checking that the modules do not communicate outside this
defined interface.
2) For a large computer program, the compilation time can be
shortened with separate compilation. This will lower costs and
also lower turn-around times. The latter is especifally important
on conversational time-sharing computers, where fast turn-around
is natural and expected.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 259
CHAPTER 4.2
4.2 Good and bad separate compilation
---------------------------------
The two main requirements of a good system for separate compilation
are security and efficiency.
By security is meant that the compiler should provide error checking
as thorough as if the modules had been compiled as one large program.
Especially important is checking the type and structure of data which
is transferred between separately compiled modules. This interface
between modules must be definable and checkable. This checking makes
it easier to design a program in such a way that you can feel sure and
even prove that the program is correct.
As a warning, look at most FORTRAN systems, where the compiler usually
does not check the data which is transferred between subroutines (as
parameters or as COMMON blocks), and where this is one of the most
common reasons for difficult-to-find errors in large FORTRAN programs.
Efficiency requires that compilation should really be done separately.
We do not want to achieve "separate compilation" by recompiling most
of the program every time, or by deferring a lot of the compilation
work to the Linking Loader (which handles the whole program) or to the
run time system (making execution time slower because of error checks
at run time).
Both these requirements cannot be completely fulfilled, since security
requires that the compiler does some scanning of other modules when
one module is compiled separately. However, the SIMULA system for
separate compilation reduces this unavoidable double-scanning to a
minimum while still retaining complete security.
Separate compilation in SIMULA can also be combined with the HIDDEN
PROTECTED concept (See Chapter 2.5.7) to provide further control of
the module interface.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 260
CHAPTER 4.3
4.3 What SIMULA concepts can be separately compiled?
-----------------------------------------------
In SIMULA, procedures and classes can be separately compiled. This
gives large freedom to the programmer to structure his program as he
wants. He can, if he so wishes, compile separately
1. Coroutines - that is e.g. routines working on a common data
buffer, one fills the buffer, but only when it is empty, the
other empties the buffer, but only when it is full.
2. Passive data blocks - a class can be a separately compiled
data block corresponding to the COMMON statement in FORTRAN.
The passive data structure can also be some more complex
structure, such as an ordered or unordered set of data
blocks, a tree structure or any other kind of data structure.
3. Program levels - by using the subclass concept of SIMULA, a
program can be written at several levels. Each level
introduces more advanced concepts based on the concepts
introduced in the previous levels, and each level is a
subclass of a separately compiled class. The main program is
a "high-level" program utilizing the "lower-level" concepts
introduced by the previous separately compiled classes.
These examples show that the SIMULA system for separate compilation is
flexible and allows the programmer to partition his program in many
conceptually different ways into separately compiled modules.
Examples will be provided in section 4.5 of this handbook.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 261
CHAPTER 4.4
4.4 How is separate compilation specified?
--------------------------------------
The use of a separately compiled module is specified by the EXTERNAL
declaration in SIMULA. You write "EXTERNAL CLASS X, Y, Z;" or
"EXTERNAL PROCEDURE A, B, C;" to tell the system that you are going to
use these separately compiled classes and procedures.
The syntax of the EXTERNAL declaration is given in chapter 2.5.6 of
this handbook. For information about EXTERNAL modules in other
languages than SIMULA, see part II of the DECsystem-10 SIMULA Language
Handbook.
In the main program, you can put these declarations anywhere a
procedure or class declaration is allowed. The separately compiled
modules will then be available throughout the block in which they are
declared, just as ordinary non-separate procedures and classes.
If you want to use a separately compiled module inside another
separately compiled module, then you put the EXTERNAL statement before
the beginning of the other separately compiled module in the main
program.
This is easiest to understand by examples, and several examples are
given in the rest of this chapter.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 262
CHAPTER 4.5
4.5 Examples of partitioning of SIMULA programs.
-------------------------------------------
4.5.1 A number of separately compiled procedures
------------------------------------------
with a common data area.
-----------------------
The FORTRAN COMMON statement defines a collection of global variables
which are available in some or all FORTRAN SUBROUTINES.
You can achieve a very similar effect in SIMULA by using a passive
separately compiled class.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
CLASS common;
BEGIN REAL x; INTEGER ARRAY y(1:10,1:100);
COMMENT etcetera.;
END;
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
EXTERNAL CLASS common;
PROCEDURE procl(tocommon);
REF (common) tocommon;
INSPECT tocommon DO
BEGIN COMMENT Body of the PROCEDURE proc1;
COMMENT here all the variables in the common data area are
directly available just as in a FORTRAN subroutine with a
COMMON statement in it;
END of proc1;
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
EXTERNAL CLASS common;
PROCEDURE proc2(tocommon);
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 263
CHAPTER 4.5.1
BEGIN COMMENT Main program;
EXTERNAL CLASS common;
EXTERNAL PROCEDURE proc1, proc2, ... etc ...;
INSPECT NEW common Do
BEGIN COMMENT Body of the main program, where all the
variables in common are directly available just as in
a FORTRAN main program with a COMMON statement;
...
proc1(THIS common);
...
proc2(THIS common);
...
END;
END of the main program;
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
In FORTRAN you can have several different labelled COMMON blocks with
different names. In the same way, you can in SIMULA have several
separately compiled CLASSes and begin each procedure by
"INSPECT tocommon1 DO INSPECT tocommon2 DO INSPECT tocommon3
DO ... etc ..."
The SIMULA CLASS is of course much more general-purpose than the
FORTRAN COMMON. The CLASS can for example contain initialization of
the data variables in the CLASS and standard procedures for handling
the data in the CLASS. All this is wellknown to someone with SIMULA
experience.
Also, you can in SIMULA have more than one copy of the same CLASS,
with different values for the data variables in them. In FORTRAN you
can only have one copy of the data in each COMMON block.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 264
CHAPTER 4.5.2
4.5.2 Each separately compiled module extends
---------------------------------------
the previous one.
----------------
In SIMULA you can write a basic CLASS defining some new concepts.
Then you can in a series of SUBCLASSES refine the basic class. Your
program will be written at different levels, where each level uses the
new concepts defined at the previous level.
For example, you may have the following levels:
Database - introduce the data structures of a relational data
base.
Datamake - introduce procedures to enter data into the relational
data base.
Datause - introduce procedures to get data from the relational
data base.
Family - introduce the special case of family relationships.
Main program - utilize the concepts to write a program using
relational data bases with family relationships in
them.
In SIMULA you can write such a program structure like this:
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 265
CHAPTER 4.5.2
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
CLASS database;
BEGIN ... END;
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
EXTERNAL CLASS database;
database CLASS datamake;
BEGIN ... END;
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
EXTERNAL CLASS database, datamake;
datamake CLASS datause;
BEGIN ... END;
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
EXTERNAL CLASS database, datamake, datause;
datause CLASS family;
BEGIN ... END;
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
BEGIN COMMENT main program;
EXTERNAL CLASS database, datamake, datause, family;
family BEGIN
... here the new concepts can be used freely ...
END;
END;
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 266
CHAPTER 4.5.3
4.5.3 A list of items is transferred to
---------------------------------
separately compiled procedures.
------------------------------
You may want to write a program to process sets of items. Usually,
when you call a separately compiled procedure, you want to transfer a
set of items to it. The sets are stored in a linear list with a
reference variable "next" referring to the next item in the list.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
CLASS item(next, number, size, label);
REF (item) next;
INTEGER number, size; TEXT label;;
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
EXTERNAL CLASS item;
PROCEDURE itemscan(itemlist);
REF (item) itemlist;
BEGIN
REF (item) scanneditem;
scanneditem:- itemlist;
WHILE scanneditem =/= NONE DO
INSPECT scanneditem DO
BEGIN COMMENT treatment of one item in the list;
...
scanneditem:- next;
END;
END;
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
BEGIN COMMENT main program;
EXTERNAL CLASS item;
EXTERNAL PROCEDURE itemscan;
REF (item) itemlist;
...
itemlist:- NEW item(itemlist,n,s,"TO OFFICE");
...
itemscan(itemlist);
...
END;
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Instead of a linear list, you could in this way transfer an arbitrary
data structure such as a tree, a ring, a relational data base of
whatever you want to transfer as data to the separately compiled
procedures and classes.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 267
CHAPTER 4.5.4
4.5.4 Separate compilation with simset and simulation.
------------------------------------------------
The standard system classes "simset" and "simulation" can themselves
be regarded as a special kind of separately compiled classes. You do
not have to declare them in any "EXTERNAL" declaration.
There are classes declared inside "simset" and "simulation", e.g.
"link" and "process". They are not themselves separately compiled
classes.
This means that a separately compiled class can be a subclass of
"simset" or of "simulation", but not a subclass of "link" or
"process".
It is not possible to write a separately compiled CLASS or PROCEDURE
using SIMSET or SIMULATION except as separately compiled subclasses to
SIMSET or to SIMULATION.
If you want to compile separately a subclass of e.g. "process" then
you can still do it. You then compile separately a subclass of
"simulation" which contains within it a subclass of "process". The
following example will show how to do it:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
simulation CLASS craneandtruck;
BEGIN
process CLASS crane;
BEGIN ... END;
process CLASS truck;
BEGIN ... END;
END;
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
EXTERNAL CLASS craneandtruck;
craneandtruck CLASS harbour;
BEGIN
process CLASS ship;
BEGIN ... END;
END;
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
BEGIN COMMENT main program;
EXTERNAL CLASS craneandtruck, harbour;
harbour BEGIN COMMENT here you can use the new processes
crane, truck and ship;
...
END;
END;
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 268
CHAPTER 4.5.4
In the above example, we first compile two subclasses of "process",
"crane" and "truck" in one separately compiled module, the class
"craneandtruck". We then compile the third subclass of "process",
"ship" in a second separately compiled module, the class "harbour".
Finally, in the main program, a simulation is programmed using the
three new processes crane, truck and ship.
4.6 A way of understanding part-compilation in SIMULA
-------------------------------------------------
A way to understand intuitively how part-compilation works is to
describe it in the following way. By this is not meant that a SIMULA
compiler necessarily will implement part-compilation in the way
described below.
When an EXTERNAL declaration occurs inside the main program, the
effect is the same as if the whole text of the separately compiled
class or procedure was copied into the main program at that point.
When an EXTERNAL declaration occurs in front of another separately
compiled class of procedure, this does not imply any such copying.
Instead, this serves to inform the compiler that when this other
module is later on copied into the main program, then the
EXTERNAL-declared module is already available at that point in the
main program.
4.7 How is part-compilation implemented in the DEC-system-10
--------------------------------------------------------
SIMULA system?
--------------
The difficulty in implementing part-compilation in a SIMULA system is
to ensure full error-checking security. To do this, the compiler must
know about other separately compiled modules when one module is
compiled, since some errors can only be found by comparing information
in several separately compiled modules.
The solution in the DEC-system-10 is that each module, when it is
compiled, outputs not only a file with the object program, but also
another file with the description of externally accessible attributes
of that module. (That is; Attributes of a separately compiled class,
parameters of a separately compiled procedure.) This other file has
the extension ".ATR".
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 269
CHAPTER 4.7
When an EXTERNAL statement is encountered, the attribute file for that
module is read in by the compiler. This means that the error-checking
can wholly be done at compile-time. There is no need to check the
parameter types of procedure parameters at run time. Most other
Algol-like languages do this parameter type checking at run time, or
else they do not check the parameter types at all.
4.8 Implementation-dependent restrictions on separate compilation
-------------------------------------------------------------
Some program changes in one module forces re-compilation of other
modules. This is just like in FORTRAN; when the number of parameters
to a FORTRAN SUBROUTINE is changed, all other SUBROUTINES which call
the changed SUBROUTINE must be modified and re-compiled, and when a
COMMON statement is modified, all SUBROUTINES containing the modified
COMMON must be re-compiled.
The difference in SIMULA is that the compiler will tell you if you
forgot to re-compile some module which had to be re-compiled. In
FORTRAN, you are usually not told, and the results may be disastrous
when you try to run the program.
The basic rule is: If a SIMULA part-compiled module is modified so
that its attributes are modified, then all other modules referring to
it by EXTERNAL statements must also be modified.
Note however, that if you only make internal changes in a module,
which do not alter the attributes, then in most cases no other module
need be re-compiled.
The DEC-system-10 SIMULA system also requires that when you compile a
separately compiled class, you must give as a parameter to the
compiler the block level of the place where it is copied into the main
program. This restriction is not as severe as you may feel initially,
since:
1. Default is the outermost block, where you usually put
EXTERNAL declarations.
2. If you do not follow this rule, the compiler tells you
exactly which modules you have to re-compile at which block
level.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 270
CHAPTER 5
CHAPTER 5 REAL TIME
---------------------
******************************IMPORTANT*******************************
This chapter describes an additional facility which will not be
included in release 1 of the DECsystem-10 SIMULA system. We have not
yet decided whether to implement this facility at all, the decision
depends on whether users of the DECsystem-10 SIMULA system require
this facility.
**********************************************************************
The simplest kind of real time application is the execution of a
conversational program running under a time-sharing system with one
external user talking to the program through a terminal such as a
display unit or a typewriter terminal.
This simple kind of conversation can already easily be programmed
using the concepts described in chapter 1-4 in this manual. The
time-sharing operating system will handle all the real time problems
for the SIMULA program.
But as soon as we want more than one real process to communicate
simultaneously with the SIMULA program, then we need more advanced
real time capabilities.
Examples:
- During a simulation, we may want to program part of the
simulation in SIMULA but let real components, for example
real human participants, play certain parts in the
simulation.
- We want to let more than one user at his terminal
simultaneously access a data base, both fetching and storing
information in it. One master program has to coordinate the
data base accesses to that two users do not simultaneously
try to update the same record. We might want to write this
program in SIMULA.
To program such applications, some additional facilities are necessary
in the SIMULA programming language.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 271
CHAPTER 5
5.1 Procedures WAIT(TERMINALQUEUE), DATAREADY and HOLD(0).
-----------------------------------------------------
The execution of a SIMULA process is only interrupted where explicit
statements like "HOLD" or "PASSIVATE" cause control to transfer from
the process to the scheduler. A common error when programming real
time programs is that one parallel process uses half-ready data,
procuced by another parallel process. For small in-core updates, a
programmer in SIMULA can avoid this error by only putting statements
like "HOLD" and "PASSIVATE" at places in the source program where data
updates are complete.
For more complex updates, a special process can be written to access
the critical data, and other processes requesting updates can be
queued to the special process. When a SIMULA process executes a
statement like "HOLD" or "PASSIVATE", then control goes to the SIMULA
scheduler, which then transfers control to another process.
"HOLD(A)" stops execution of the current process but asks the SIMULA
scheduler to restart it after A time units. If A is zero, then the
current process is stopped and placed at the end of a queue of
currently active processes. If a number of processes successively
make "HOLD(0.0)" then they will thus get CPU power in a round robin
fashion.
A SIMULA programmer can thus ensure fast response to external
interrupts by not making too much computations between successive
"HOLDS".
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 272
CHAPTER 5
"PASSIVATE" stops the current process indefinitely, it must be
activated again from some other process.
Processes waiting for external interrupts are put into a special queue
called TERMINALQUEUE. As soon as control is transferred to the SIMULA
scheduler (e.g. by calls to "HOLD" or "PASSIVATE") then the scheduler
first scans this queue to see if data has arrived from the input
device associated with the terminal process.
If a process is found in the TERMINALQUEUE for which data has arrived
on the associated input device, then the SIMULA scheduler activates
this process immediately.
The event created by the first external interrupt found is thus placed
in front of other currently active processes in the sequencing set.
This, however, is not done at the time of the interrupt, the placing
is done at the time of the next activation of the scheduler after the
interrupt.
Inside a process, a call "WAIT(TERMINALQUEUE)" will thus tell the
system to make this process passive, but to reactivate it as soon as
new data has arrived on the input device associated with the process.
A new "BOOLEAN" standard procedure "DATAREADY" is also introduced.
Dataready is an attribute to INFILE and is TRUE if and only if data is
available (i.e. has arrived from the terminal device) for reading
with INIMAGE.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 273
CHAPTER 5
5.2 Procedures TIMEOFDAY, SYNCHRONIZE and DESYNCHRONIZE
--------------------------------------------------
For real time applications, we may also want to synchronize simulated
time with real time. For this there are three new standard
procedures:
REAL PROCEDURE timeofday; COMMENT gives time in seconds since the
beginning of the current day;
PROCEDURE synchronize(timeunit); REAL timeunit; COMMENT this
procedure starts synchronization of real and simulated time;
PROCEDURE desynchronize; COMMENT and this stops synchronization;
Of course perfect synchronization of real and simulated time is not
possible since the speed of the computer itself is not infinite. By
synchronization is meant that the simulated time since the beginning
of the current synchronization period must never be larger than the
real time since the same beginning.
If the SIMULA scheduler finds that the next process to be scheduled
has a too large simulated time, then the SIMULA scheduler lets the
SIMULA program go to sleep for the necessary time interval. Any
interrupts caused by input will however start the SIMULA program
again. (On a DEC system-10 computer, the HIBERNATE UUO can be used to
program this.)
The parameter "timeunit" to the procedure "synchronize" is there since
the time unit may not be the same in the simulation and in the real
world. "timeunit" is the size of the simulation time unit in seconds.
Thus, if simulated time is measured in seconds, "timeunit" should be
1.0, if simulated time is measured in hours, "timeunit" should be
60*60.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 274
CHAPTER 5
5.3 Application examples
--------------------
In this section you can see how the new concepts can be used. Some
examples will be given of real time programs written in SIMULA using
the new concepts.
The programs are not always complete. Three dots indicate places
where something has been left out.
5.3.1 Simultaneous, uninterfered dialogue between
-------------------------------------------
the computer and several real terminals
---------------------------------------
One master terminal reads file specifications for the other terminals
and starts up one copy of the SIMULA CLASS "terminal" for each of the
other terminals. Each of these "terminal processes" will open the
connection to its real terminal, and then go into a loop of (a)
waiting for input and (b) producing answers.
Each of these terminal loops will go on independently of the other,
and the SIMULA scheduler will distribute control between the "terminal
processes".
terminalprocess CLASS terminal(file specifications);
TEXT file specifications;
INSPECT fromterminal DO
INSPECT NEW outfile(file specifications) DO
BEGIN
PROCEDURE open terminal connections; ...
PROCEDURE read the input and produce an answer; ...
open terminal connections;
WHILE TRUE DO
BEGIN
wait(terminalqueue);
read the input and produce an answer;
END;
END;
WHILE TRUE DO
BEGIN
PROCEDURE
read file specifications for a conversational terminal;
...
TEXT file specifications;
wait(terminalqueue);
read file specifications for a conversational terminal;
ACTIVATE NEW terminal(NEW infile(file specifications),
END;
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 275
CHAPTER 5
5.3.2 Data base system, several terminals
-----------------------------------
use the same data base
----------------------
This is a very simple example of a data base system with several
conversational terminals which independently put requests (questions
or updates) to a data base. The actual data base accesses must be
done for only one request at a time to avoid errors when one terminal
tries to read what another terminal is updating.
The SIMULA program contains one process for each terminal and one
process for the data base.
The terminal processes wait for input from their respective terminals.
When a data base request has been received, the terminal process is
put into a queue of data base requests.
The data base process takes one terminal process at a time from this
queue and processes the data base request. Thereafter, the data base
process ACTIVATEs the terminal process again. When ACTIVATEd, this
terminal process writes the answer to its terminal and waits for new
requests from it.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 276
CHAPTER 5
REF (head) request queue; REF (data base) the data base;
terminalprocess CLASS terminal(file specifications);
TEXT file specifications;
INSPECT fromterminal DO
INSPECT NEW outfile(file specifications) DO
BEGIN
PROCEDURE open terminal line; ...
PROCEDURE read and prepare data base request; ...
PROCEDURE write the answer to the request; ...
WHILE TRUE DO
BEGIN
wait(terminalqueue);
read and prepare data base request;
ACTIVATE the data base;
wait(request queue);
write the answer to the request;
END;
END;
process CLASS data base;
INSPECT NEW directfile(data base file specifications) DO
BEGIN
PROCEDURE open data base file; ...
PROCEDURE
put the request to the data base and find the answer;
...
open data base file;
WHILE TRUE DO
INSPECT request queue.first WHEN terminal DO
BEGIN
out; COMMENT to remove the terminal from the request
queue;
put the request to the data base and find the answer;
ACTIVATE THIS terminal;
END OTHERWISE passivate;
END;
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 277
CHAPTER 5
5.3.3 Limited response time for the terminal operator
-----------------------------------------------
This is a very simple example of a program which is coordinated with
the time in the real world. A question is given to a terminal
operator and the program waits for an answer. The program should take
different action depending on whether the answer is received within 60
seconds or not.
To do this, the new standard procedure SYNCHRONIZE is used to
synchronize real time with the simulated time in SIMULA.
terminalprocess CLASS terminal(file specifications);
TEXT file specifications;
INSPECT fromterminal DO
INSPECT NEW outfile(file specifications) DO
BEGIN
REAL questiontime;
PROCEDURE open terminal connection; ...
PROCEDURE write question to the terminal; ...
PROCEDURE process fast answer; ...
PROCEDURE process slow answer; ...
open terminal connection;
synchronize(1.0);
write question to the terminal;
questiontime:= time;
wait(terminalqueue);
IF time - questiontime < 60.0 THEN
process fast answer ELSE
process slow answer;
END;
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 278
CHAPTER 5
5.3.4 A conversational time-sharing system
------------------------------------
The conversational time-sharing system in this example could be an
interpreter for a language like APL or FOCAL or AID.
Highest priority is given to those input commands which are to be
performed directly. Lower priority is given to input commands
requesting the execution of a stored program. When several stored
programs are in execution at the same time, CPU power is distributed
between them in a round robin fashion letting each program perform one
statement in the stored program before continuing to the next program.
terminalprocess CLASS terminal(file specifications);
TEXT file specifications;
INSPECT fromterminal DO
INSPECT NEW outfile(file specifications) DO
BEGIN
PROCEDURE open terminal connections; ...
PROCEDURE read the input and produce an answer;
BEGIN
BOOLEAN more statements, execute command;
PROCEDURE read and interpret an input line; ...
PROCEDURE execute the next stored program statement;
...
PROCEDURE perform the command from the input line; ...
read and interpret an input line;
IF NOT execute command THEN
perform the command from the input line ELSE
WHILE more statements DO
BEGIN
HOLD(0); COMMENT to transfer control to another
process;
execute the next stored program statement;
END;
END;
open terminal connections;
WHILE TRUE DO
BEGIN
wait(terminalqueue);
read the input and produce an answer;
END;
END;
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 279
CHAPTER 5
5.3.5 Coordinated control of simultaneous real processes
--------------------------------------------------
When a real time computer program communicates with several
simultaneous processes in the real world, the computer program may
want to control itself or the real-world processes depending on the
results in the various processes.
Example 1: A simulation program may want to continue the simulation
when all the terminals have answered certain questions.
Example 2: A process control program may monitor several real-world
processes, and initiate other real-world actions when previous
processes are ready.
This is similar to PERT-networks in planning, where certain actions
must wait for other actions to finish.
To illustrate this, a simple example assumes a robot with three arms.
A process "put nail in board" in initiated. This process initiates
three simultaneous processes, the first arm gets a hammer, the second
arm gets a nail, and the third arm gets a board. When all these three
precesses are finished, the hammer is used to push the nail into the
board.
In other languages, special constructs like "fork" and "join" are used
to create parallel processes and then continue when all the processes
are ready. But the same thing is very simple to program in SIMULA,
and in SIMULA we do not have to wtin until a process is fully
finished, we can also easily start a later process when still runnning
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 280
APPENDIX A
APPENDIX A
----------
ISO-R 646 (=ASCII) Characters as used in SIMULA source programs
outside comments.
Character Manual Octal Decimal Comment
--------- ------ ----- ------- -------
Null ^@ 000 0 Ignored on source program
input.
Control-A ^A 001 1 Illegal in SIMULA source
programs.
Control-B ^B 002 2 Monitor command. Illegal in
SIMULA source programs.
Control-C ^C 003 3 Monitor command. Illegal in
SIMULA source programs.
Control-D ^D 004 4 Illegal in SIMULA source
programs.
Control-E ^E 005 5 Illegal in SIMULA source
programs
Control-F ^F 006 6 Monitor command. Illegal in
SIMULA source programs
Bell ^G 007 7 Illegal in SIMULA source
programs.
Backspace ^H 010 8 Illegal in SIMULA source
programs.
Tab ^I HT 011 9 Illegal, but replaced by space
in character and text
constants, otherwise a
separator.
Line Feed ^J LF 012 10 Increments line number (1),
otherwise replaced by a space
in character constants,
ignored in text constants and
interpreted as a separator
outside.
---------------------------------------------------
(1) Certain successions of these characters indicate only one line
number incrementation for the whole group of characters.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 281
APPENDIX A
Vertical Tab VT 013 11 See "Line Feed" above.
Form Feed FF 014 12 Gives new page in program
listing.
Carriage return CR 015 13 Ignored in text constants,
treated as a separator outside
text constants.
Control-N ^N 016 14 Illegal in SIMULA source
programs.
Control-O ^O 017 15 Monitor command. Illegal in
SIMULA source programs.
Control-P ^P 020 16 Monitor command. Illegal in
SIMULA source programs.
Control-Q ^Q 021 17 Monitor command. Illegal in
SIMULA source programs.
Control-R ^R 022 18 Monitor command. Illegal in
SIMULA source programs.
Control-S ^S 023 19 Monitor command. Illegal in
SIMULA source programs.
Control-T ^T 024 20 Monitor command. Illegal in
SIMULA source programs.
Control-U ^U 025 21 Monitor command. Illegal in
SIMULA source programs.
Control-V ^V 026 22 Illegal in SIMULA source
programs.
Control-W ^W 027 23 Illegal in SIMULA source
programs.
Control-X ^X 030 24 Illegal in SIMULA source
programs.
Control-Y ^Y 031 25 Illegal in SIMULA source
programs.
Control-Z ^Z 032 26 Signifies end-of-file in input
data to a SIMULA program.
Illegal in SIMULA source
programs.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 282
APPENDIX A
Altmode ^[ 033 27 Illegal in SIMULA source
programs.
Control-Shift-L ^\ 034 28 Illegal in SIMULA source
programs.
Control-Shift-M ^] 035 29 Illegal in SIMULA source
programs.
Control-Shift-N ^^ 036 30 Illegal in SIMULA source
programs.
Control-Shift-O ^_ 037 31 Illegal in SIMULA source
programs.
Space 040 32 Ignored in arithmetic
constants, accepted in text
and character constants,
otherwise a separator(2).
! 041 33 Valid in text and character
constants, also an alternative
to the SIMULA word COMMENT.
" 042 34 Start and end of text
constants, doubled inside text
constants, valid inside
character constants.
# 043 35 Treated as a letter in source
programs, Swedish letter "AE".
Equivalent to "{" in
identifiers.
$ 044 36 Treated as a letter in source
programs, Swedish letter "AA".
Equivalent to "}" in
identifiers.
% 045 37 Only allowed in text and
character constants(2).
& 046 38 Used to indicate exponent part
of [LONG]REAL constants,
otherwise only allowed in TEXT
and CHARACTER CONSTANTS(2).
---------------------------------------------
(2) This appendix does not treat the use of characters in comments.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 283
APPENDIX A
' 047 39 Valid inside text and
character constants, otherwise
start of a character constant.
( 050 40 Valid inside text and
character constants. Used in
expressions, for procedure
parameters and indices and
array bounds.
) 051 41 See (.
* 052 42 Valid inside text and
character constants, otherwise
multiplication (*) or
exponentiation operator (**).
+ 053 43 Valid inside text and
character constants, otherwise
addition operator.
, 054 44 Valid inside text and
character constants, otherwise
separator between parameters
and between indices.
- 055 45 Valid inside text and
character constants, otherwise
subtract and used in ":-"
operator.
. 056 46 Valid inside text and
character constants, decimal
point in real constants,
separates reference variable
and class parameter for remote
accessing.
/ 057 47 Valid inside text and
character constants, otherwise
division and relational (used
in =/=) operator.
0 060 48 Digit.
1 061 49 Digit.
2 062 50 Digit.
3 063 51 Digit.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 284
APPENDIX A
4 064 52 Digit.
5 065 53 Digit.
6 066 54 Digitl
7 067 55 Digit.
8 070 56 Digit.
9 071 57 Digit.
: 072 58 Itself in text and character
constants. Used to separate
lower and upper array bound,
used in ":=" and ":-"
operator.
; 073 59 Itself in text and character
constants. Signifies end of
comment, end of declaration or
end of statement.
< 074 60 Itself in text and character
constants. Otherwise
comparative operator
= 075 61 Itself in text and character
constants. Used in ":="
operator. Used for several
comparative operators.
> 076 62 Itself in text and character
constants. Otherwise
comparative operator.
? 077 63 Itself in text and character
constants. Otherwise
illegal(2).
@ 100 64 Swedish letter "OE".
Equivalent to "`" in
identifiers.
A 101 65 Letter.
B 102 66 Letter.
C 103 67 Letter.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 285
APPENDIX A
D 104 68 Letter.
E 105 69 Letter.
F 106 70 Letter.
G 107 71 Letter.
H 110 72 Letter.
I 111 73 Letter.
J 112 74 Letter.
K 113 75 Letter.
L 114 76 Letter.
M 115 77 Letter.
N 116 78 Letter.
O 117 79 Letter.
P 120 80 Letter.
Q 121 81 Letter.
R 122 82 Letter.
S 123 83 Letter.
T 124 84 Letter.
U 125 85 Letter.
V 126 86 Letter.
W 127 87 Letter.
X 130 88 Letter.
Y 131 89 Letter.
Z 132 90 Letter.
[ 133 91 Itself inside text and
character constants, otherwise
array index indicator.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 286
APPENDIX A
\ 134 92 Itself inside text and
character constants, otherwise
the "NOT" operator and used in
the "\=" operator.
] 135 93 Itself inside text and
character constants, otherwise
array index indicator.
^ 136 94 Itself inside text and
character constants, otherwise
exponentiation.
_ 137 95 Itself inside text and
character constants, allowed
in identifiers.
` 140 96 Swedish letter "oe".
Equivalent to "@" in
identifiers.
a 141 97 Letter. Equivalent to "A" in
identifiers.
b 142 98 Letter. Equivalent to "B" in
identifiers.
c 143 99 Letter. Equivalent to "C" in
identifiers.
d 144 100 Letter. Equivalent to "D" in
identifiers.
e 145 101 Letter. Equivalent to "E" in
identifiers.
f 146 102 Letter. Equivalent to "F" in
identifiers.
g 147 103 Letter. Equivalent to "G" in
identifiers.
h 150 104 Letter. Equivalent to "H" in
identifiers.
i 151 105 Letter. Equivalent to "I" in
identifiers.
j 152 106 Letter. Equivalent to "J" in
identifiers.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 287
APPENDIX A
k 153 107 Letter. Equivalent to "K" in
identifiers.
l 154 108 Letter. Equivalent to "L" in
identifiers.
m 155 109 Letter. Equivalent to "M" in
identifiers.
n 156 110 Letter. Equivalent to "N" in
identifiers.
o 157 111 Letter. Equivalent to "O" in
identifiers.
p 160 112 Letter. Equivalent to "P" in
identifiers.
q 161 113 Letter. Equivalent to "Q" in
identifiers.
r 162 114 Letter. Equivalent to "R" in
identifiers.
s 163 115 Letter. Equivalent to "S" in
identifiers.
t 164 116 Letter. Equivalent to "T" in
identifiers.
u 165 117 Letter. Equivalent to "U" in
identifiers.
v 166 118 Letter. Equivalent to "V" in
identifiers.
w 167 119 Letter. Equivalent to "W" in
identifiers.
x 170 120 Letter. Equivalent to "X" in
identifiers.
y 171 121 Letter. Equivalent to "Y" in
identifiers.
z 172 122 Letter. Equivalent to "Z" in
identifiers.
{ 173 123 Swedish letter "ae".
Equivalent to "#" in
identifiers.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 288
APPENDIX A
174 124 Only legal in text and
character constants(2).
$ 175 125 Swedish letter "aa".
Equivalent to "$" in
identifiers.
~ 176 126 Only allowed in text and
character constants(2).
Rubout RO 177 127 Ignored in source program
input.
----------------------------------------------------------------------
Note that the use of the Swedish letters A with two dots above it
(AE), A with a circle above it (AA) and O with two dots above it (OE)
and their lower case representations is not allowed in identifiers
according to the SIMULA 67 Standard. The DECsystem-10 SIMULA compiler
accepts these letters in identifiers, but programmers are recommended
not to use them if they want their programs to conform to the SIMULA
standard.
Character constants in SIMULA are initialized to CHAR(0).
When comparing two text strings or character constants, the numerical
values in the table above are used.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 289
APPENDIX B
APPENDIX B
----------
THE SYSTEM DEFINED PROCEDURES
-----------------------------
Calls to system defined procedures conform to the syntax of calls to
declared procedures. The identifier of a standard procedure may be
redefined to have another meaning at any block level. The identifier
then assumes the new meaning throughout the scope of the block.
Standard procedures are available to any SIMULA program.
The system defined procedures detailed below are grouped into the
following sections
Arithmetic functions
CHARACTER handling
Random drawing procedures
Utility procedures
For details of other procedures:
for TEXT handling see Chapter 3, section 4
for Sequencing procedures see Chapter 3, section 1
for Procedures local to SIMSET see Chapter 3, section 2
for Procedures local to SIMULATION see Chapter 3, section 3
for Procedures local to subclasses
of CLASS file see Chapter 5, section 5
A skeleton outline of all system defined procedures and classes is
given as APPENDIX C.
Arithmetic functions
--------------------
Certain identifiers, expressed as procedures are defined by the SIMULA
system for standard arithmetic functions.
ABS(E) modulus (absolute value) of E
ARCCOS(E) *
ARCSIN(E) *
ARCTAN(E) return the principal values of the arc-cosine,
arc-sine, arc-tangent of E (the result is measured in
radians)
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 290
APPENDIX B
COS(E)
SIN(E)
TAN(E) * return the cosine, sine, tangent of E (E is measured in
radians)
COSH(E) *
SINH(E) *
TANH(E) * return the hyperbolic cosine, hyperbolic sine,
hyperbolic tangent of E
EXP(E) exponential function of E (e^E).
LN(E) natural logarithm of E (ln E). If E <= 0, a run time
error results.
SQRT(E) returns the square root of E if E >= 0. If E < 0, a
run time error results.
The above 13 functions operate on arithmetic arguments. If the type
of E is INTEGER or REAL, then the function value is of type REAL. If
the type of E is LONG REAL, then the function value is of type LONG
REAL. However, LONG REAL versions of the functions marked with an
asterisk above (ARCCOS, ARCSIN, TAN, COSH, SINH and TANH) will not
initially be available in the DECsystem-10 SIMULA system. Therefore,
even if E is of type LONG REAL, the REAL function will be used and a
warning message will be given at compile-time.
SIGN(E) sign of the value of E
1 if E > 0
= 0 if E = 0
-1 if E < 0
ENTIER(E) largest whole number less than or equal to E (equal to
or to the left of E on the real axis).
e.g. ENTIER(5.3) = 5
ENTIER(-4.7) = -5
ENTIER(1) = 1
The above 2 functions operate upon [LONG] REAL or INTEGER values of E
and yield values of type INTEGER.
MOD(M,N) M modulo N, that is
M-(M//N)*N
e.g. MOD (7,3) is 1
MOD (-48,5) is -3
Note that MOD is not equivalent to the mathematical modulo function
for negative arguments.
The function operates on INTEGER arguments, [LONG]REAL arguments being
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 291
APPENDIX B
rounded. The result is INTEGER. We are investigating the possibility
of modifying the MOD function for negative values of M to the
definition M-ENTIER(M/N)*N.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 292
APPENDIX B
CHARACTER handling
------------------
Two CHARACTER subsets are defined by the standard procedures:
BOOLEAN PROCEDURE DIGIT(C); CHARACTER C;
----------------------------------------
which is TRUE if C is a digit, FALSE otherwise.
BOOLEAN PROCEDURE LETTER(C); CHARACTER C;
-----------------------------------------
which is TRUE if C is an upper or lower case letter, FALSE otherwise.
The collating sequence defines a one-one mapping between the INTEGERS
and the internal CHARACTER representation (see APPENDIX A).
INTEGER PROCEDURE RANK(C); CHARACTER C;
---------------------------------------
returns a value in the range 0 through 127.
CHARACTER PROCEDURE CHAR(N); INTEGER N;
--------------------------------------
if the parameter value is not in the range 0 through 127, a run time
error results. Otherwise the procedure returns the CHARACTER with
value N.
Examples:
--------
RANK('+') = 43
RANK('A') = 65
CHAR(57) = '9'
CHAR(8R40) = ' '
RANK(CHAR(127)) = 127
DIGIT(C) = RANK(C) >= 48 AND RANK(C) <=57
DIGIT(C) = C >= '0' AND C <= '9'
LETTER(C) = (C>= 'A' AND C <= 'Z')
OR (C >= 'a' AND C <= 'z')
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 293
APPENDIX B
Random drawing procedures
-------------------------
The random drawing procedures produce, in successive calls, a stream
of random numbers taken from a specified distribution. As a side
effect, the procedures update the stream variable U (which must always
be an INTEGER variable) thus advancing the specified stream by one
step.
BOOLEAN PROCEDURE DRAW(A,U); NAME U; REAL A; INTEGER U;
-------------------------------------------------------
If 0 < A < 1, the value is TRUE with probability A, FALSE
with probability 1-A.
If A <= 0, the value is always FALSE.
If A >= 1, the value is always TRUE.
INTEGER PROCEDURE RANDINT(A,B,U); NAME U; INTEGER A,B,U;
--------------------------------------------------------
If A <= B, the value is one of the INTEGERS
A, A+1, A+2, ....., B-1, B
with equal probability.
If A > B, a run time error results.
REAL PROCEDURE UNIFORM(A,B,U); NAME U; REAL A,B; INTEGER U;
-----------------------------------------------------------
If A < B, the value is uniformly distributed between A and B.
If A >= B, a run time error results.
REAL PROCEDURE NORMAL(A,B,U); NAME U; REAL A,B; INTEGER U;
----------------------------------------------------------
The value is normally distributed with mean "A" and standard
deviation "B". An approximation function is used for the
normal distribution.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 294
APPENDIX B
REAL PROCEDURE NEGEXP(A,U); NAME U; REAL A; INTEGER U;
------------------------------------------------------
If A > 0, the value is drawn from a negative exponential
distribution with mean "1/A". This is the same as a random
waiting time in a Poisson distributed arrival pattern with an
expected number of arrivals per time unit equal to "A".
If A <= 0, a run time error results.
INTEGER PROCEDURE POISSON(A,U); NAME U; REAL A; INTEGER U;
----------------------------------------------------------
The value is a drawing from the Poisson distribution with
parameter "A".
If A > 20.0, the value is approximated by
ENTIER(0.5 + NORMAL(A,SQRT(A),U)).
If A < 0, the value is zero.
REAL PROCEDURE ERLANG(A,B,U); NAME U; REAL A,B; INTEGER U;
----------------------------------------------------------
If A <= 0 or B <= 0, a run time error results.
If A > 0 and B > 0, then the value is a drawing from the
Erlang distribution with mean "1/A" and standard deviation
"1/(A*SQRT(B)).
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 295
APPENDIX B
INTEGER PROCEDURE DISCRETE(A,U); NAME U; REAL ARRAY A; (1)
------------------------------------------------------
INTEGER U;
----------
The one dimensional REAL ARRAY A, augmented by a unit element
one to the right, is interpreted as a step function of the
subscript, defining a discrete (cumulative) distribution
function. The function value is an INTEGER in the range
"A.lower bound" through "A.upper bound+1"
It is defined as the smallest I such that
A(I) > U
where U is a basic drawing and A(upper bound+1) = 1.0.
REAL PROCEDURE LINEAR(A,B,U); NAME U; REAL ARRAY A,B; (1)
-----------------------------------------------------
INTEGER U;
----------
The value is a drawing from a cumulative distribution
function F, which is obtained by linear interpolation in a
non-equidistant table defined by A and B, such that
A(K) = F(B(I))
It is assumed that A and B are one dimensional REAL ARRAYS
with the same bounds, that the first and last elements of A
are equal to 0.0 and 1.0 respectively, and that
A(I) >= A(J)
for I > J
B(I) >= B(J)
(1) NOTE. NO CHECKING OF THE CORRECTNESS OF THE ARRAY PARAMETER
CONTENTS IS PERFORMED.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 296
APPENDIX B
INTEGER PROCEDURE HISTD(A,U); NAME U; REAL ARRAY A; (1)
---------------------------------------------------
INTEGER U;
----------
The value is an INTEGER in the range "A.lower bound" through
"A.upper bound", where A is a one dimensional REAL ARRAY
interpreted as a histogram defining the relative frequencies
of values.
Utility procedures
------------------
PROCEDURE HISTO(A,B,C,D); REAL ARRAY A,B; (1)
REAL C,D;
A call on HISTO updates a histogram defined by the one dimensional
ARRAYS (INTEGER or REAL) A,B according to observation C with weight D.
A(I) is incremented by D, where I is the smallest INTEGER such that
C <= B(i). It is assumed that the length of A is one greater than the
length of B. The last element of A corresponds to those observations
which are greater than all the elements of B.
PROCEDURE LOWTEN(C); CHARACTER C;
---------------------------------
Without use of LOWTEN, the CHARACTER 'E' represents the exponent sign
in any numeric item to edited or de-edited. A call on "LOWTEN" with
actual parameter "EXPSIGN" will replace "E" by the value of EXPSIGN in
future editing and de-editing. C must not be a digit, sign, period,
or an ASCII character with RANK <= 32 or RANK = 127.
(1) Note. No checking of the correctness of the array parameter
contents is performed.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 297
APPENDIX C
APPENDIX C
----------
SKELETON OF THE SYSTEM CLASSES AND SYSTEM PROCEDURES
----------------------------------------------------
Contents:
--------
SYSTEM DEFINED PROCEDURES
ARITHMETIC FUNCTIONS
CHARACTER HANDLING
TEXT HANDLING
SEQUENCING PROCEDURES
RANDOM DRAWING PROCEDURES
UTILITY PROCEDURES
SYSTEM DEFINED CLASSES
CLASS SIMSET
CLASS SIMULATION
SUBCLASSES of file
PROGRAM ENVIRONMENT
SYSTEM DEFINED PROCEDURES
-------------------------
ARITHMETIC FUNCTIONS
--------------------
*REAL PROCEDURE ABS(X); REAL X;
*REAL PROCEDURE ARCCOS(X); REAL X;
*REAL PROCESURE ARCSIN(X); REAL X;
REAL PROCEDURE ARCTAN(X); REAL X;
REAL PROCEDURE COS(X); REAL X;
*REAL PROCEDURE COSH(X); REAL X;
REAL PROCEDURE EXP(X); REAL X;
REAL PROCEDURE LN(X); REAL X;
REAL PROCEDURE SIN(X); REAL X;
*REAL PROCEDURE SINH(X); REAL X;
REAL PROCEDURE SQRT(X); REAL X;
*REAL PROCEDURE TAN(X); REAL X;
*REAL PROCEDURE TANH(X); REAL X;
N.B. If the actual parameter on a call to some of the above
non-starred procedures is LONG REAL, then a LONG REAL result will be
returned.
INTEGER PROCEDURE ENTIER(X); REAL X;
INTEGER PROCEDURE MOD(X,Y); INTEGER X,Y;
INTEGER PROCEDURE SIGN(X); REAL X;
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 298
APPENDIX C
CHARACTER HANDLING
------------------
BOOLEAN PROCEDURE DIGIT(C); CHARACTER C;
BOOLEAN PROCEDURE LETTER(C); CHARACTER C;
CHARACTER PROCEDURE CHAR(N); INTEGER N;
INTEGER PROCEDURE RANK(C); CHARACTER C;
TEXT HANDLING
-------------
TEXT OBJECT GENERATION
----------------------
TEXT PROCEDURE COPY(T); VALUE T; TEXT T;
TEXT PROCEDURE BLANKS(N); INTEGER N;
TEXT ATTRIBUTES
---------------
CHARACTER PROCEDURE GETCHAR;
INTEGER PROCEDURE GETFRAC;
INTEGER PROCEDURE GETINT;
REAL PROCEDURE GETREAL;
INTEGER PROCEDURE LENGTH;
TEXT PROCEDURE MAIN;
BOOLEAN PROCEDURE MORE;
INTEGER PROCEDURE POS;
PROCEDURE PUTCHAR(C); CHARACTER C;
PROCEDURE PUTFIX(X,N); [LONG] REAL X; INTEGER N;
PROCEDURE PUTFRAC(I,N); INTEGER I,N;
PROCEDURE PUTINT(I); INTEGER I;
PROCEDURE PUTREAL(X,N); [LONG] REAL X; INTEGER N;
PROCEDURE SETPOS(N); INTEGER N;
TEXT PROCEDURE STRIP;
TEXT PROCEDURE SUB(I,N); INTEGER I,N;
SEQUENCING PROCEDURES
---------------------
PROCEDURE CALL(X); REF(anyclass)X;
PROCEDURE DETACH;
PROCEDURE RESUME(Y); REF(anyclass)X;
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 299
APPENDIX C
RANDOM DRAWING PROCEDURES
-------------------------
INTEGER PROCEDURE DISCRETE(A,U); NAME U; ARRAY A; INTEGER U;
BOOLEAN PROCEDURE DRAW(A,U); NAME U; REAL A; INTEGER U;
REAL PROCEDURE ERLANG(A,B,U); NAME U; REAL A,B; INTEGER U;
INTEGER PROCEDURE HISTD(A,U); NAME U; ARRAY A; INTEGER U;
REAL PROCEDURE LINEAR(A,B,U); NAME U; ARRAY A,B; INTEGER U;
REAL PROCEDURE NEGEXP(A,U); NAME U; REAL A; INTEGER U;
REAL PROCEDURE NORMAL(A,B,U); NAME U; REAL A,B; INTEGER U;
INTEGER PROCEDURE POISSON(A,U); NAME U; REAL A; INTEGER U;
INTEGER PROCEDURE RANDINT(A,B,U); NAME U; INTEGER A,B,U;
REAL PROCEDURE UNIFORM(A,B,U); NAME U; REAL A,B; INTEGER U;
UTILITY PROCEDURES
------------------
PROCEDURE HISTO(A,B,C,D); ARRAY A,B; REAL C,D;
PROCEDURE LOWTEN(C); CHARACTER C;
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 300
APPENDIX C
SYSTEM DEFINED CLASSES
----------------------
CLASS SIMSET:
------------
CLASS SIMSET;
BEGIN CLASS LINKAGE;
BEGIN REF(LINK) PROCEDURE SUC;
REF(LINK) PROCEDURE PRED;
REF(LINKAGE) PROCEDURE PREV;
END ***LINKAGE*** ;
LINKAGE CLASS LINK;
BEGIN PROCEDURE OUT;
PROCEDURE INTO(H); REF(HEAD)H;
PROCEDURE PRECEDE(X); REF(LINKAGE)X;
PROCEDURE FOLLOW(X); REF(LINKAGE)X;
END ***LINK*** ;
LINKAGE CLASS HEAD;
BEGIN REF(LINK) PROCEDURE FIRST;
REF(LINK) PROCEDURE LAST;
PROCEDURE CLEAR;
BOOLEAN PROCEDURE EMPTY;
INTEGER PROCEDURE CARDINAL;
END ***HEAD*** ;
END ***SIMSET*** ;
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 301
APPENDIX C
CLASS SIMULATION
----------------
SIMSET CLASS SIMULATION;
BEGIN LINK CLASS PROCESS;
BEGIN BOOLEAN PROCEDURE IDLE;
BOOLEAN PROCEDURE TERMINATED;
REAL PROCEDURE EVTIME;
REF(PROCESS) PROCEDURE NEXTEV;
END ***PROCESS*** ;
REF(PROCESS) PROCEDURE CURRENT;
LONG REAL PROCEDURE TIME;
PROCEDURE HOLD(T); REAL T;
PROCEDURE PASSIVATE;
PROCEDURE WAIT(Q); REF(HEAD)Q;
PROCEDURE CANCEL(X); REF(PROCESS)X;
PROCEDURE ACCUM(A,B,C,D); NAME A,B,C;
REAL A,B,C,D;
REF(main program)MAIN;
<ACTIVATION-statements>
END;
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 302
APPENDIX C
SUBCLASSES of file
------------------
CLASS file(name); VALUE name; TEXT name;
VIRTUAL : PROCEDURE OPEN, CLOSE;
BEGIN TEXT IMAGE;
INTEGER PROCEDURE LENGTH;
BOOLEAN PROCEDURE MORE;
INTEGER PROCEDURE POS;
PROCEDURE SETPOS(I); INTEGER I;
END ***file*** ;
file CLASS INFILE; VIRTUAL : BOOLEAN PROCEDURE ENDFILE;
PROCEDURE IMAGE;
BEGIN PROCEDURE CLOSE;
BOOLEAN PROCEDURE ENDFILE;
CHARACTER PROCEDURE INCHAR;
PROCEDURE INIMAGE;
INTEGER PROCEDURE ININT;
INTEGER PROCEDURE INFRAC;
REAL PROCEDURE INREAL;
TEXT PROCEDURE INTEXT(N); INTEGER N;
BOOLEAN PROCEDURE LASTITEM;
PROCEDURE OPEN(T); TEXT T;
END ***INFILE*** ;
file CLASS OUTFILE; VIRTUAL : PROCEDURE OUTIMAGE;
BEGIN PROCEDURE CLOSE;
PROCEDURE OPEN(T); TEXT T;
PROCEDURE OUTCHAR(C); CHARACTER C;
PROCEDURE OUTFIX(R,N,W); [LONG] REAL R; INTEGER N,W;
PROCEDURE OUTFRAC(I,N,W); INTEGER I,N,W;
PROCEDURE OUTIMAGE;
PROCEDURE BREAKOUTIMAGE;
PROCEDURE OUTINT(I,W); INTEGER I,W;
PROCEDURE OUTREAL(X,N,W); [LONG] REAL R; INTEGER N,W;
PROCEDURE OUTTEXT(T); VALUE T; TEXT T;
END ***OUTFILE*** ;
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 303
APPENDIX C
OUTFILE CLASS PRINTFILE;
BEGIN PROCEDURE CLOSE;
PROCEDURE EJECT(N); INTEGER N;
INTEGER PROCEDURE LINE;
PROCEDURE LINESPERPAGE(N); INTEGER N;
PROCEDURE OPEN(T); TEXT T;
PROCEDURE OUTIMAGE;
PROCEDURE SPACING(N); INTEGER N;
END ***PRINTFILE*** ;
file CLASS DIRECTFILE; VIRTUAL : PROCEDURE LOCATE OUTIMAGE, INIMAGE;
BOOLEAN PROCEDURE ENDFILE;
BEGIN PROCEDURE CLOSE;
BOOLEAN PROCEDURE ENDFILE;
CHARACTER PROCEDURE INCHAR;
INTEGER PROCEDURE INFRAC;
PROCEDURE INIMAGE;
INTEGER PROCEDURE ININT;
LONG REAL PROCEDURE INREAL;
TEXT PROCEDURE INTEXT(N); INTEGER N;
BOOLEAN PROCEDURE LASTITEM;
PROCEDURE LOCATE(I); INTEGER I;
INTEGER PROCEDURE LOCATION;
PROCEDURE OPEN(T); TEXT T;
PROCEDURE OUTCHAR(C); CHARACTER C;
PROCEDURE OUTFIX(X,N,W); [LONG] REAL X; INTEGER N,W;
PROCEDURE OUTFRAC(I,N,W); INTEGER I,N,W;
PROCEDURE OUTIMAGE;
PROCEDURE OUTINT(I,W); INTEGER I,W;
PROCEDURE OUTREAL(X,N,W); [LONG] REAL X; INTEGER N,W;
PROCEDURE OUTTEXT(T); VALUE T; TEXT T;
END ***DIRECTFILE*** ;
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 304
APPENDIX C
PROGRAM ENVIRONMENT
-------------------
A user's program behaves as though enclosed as below: (1)
basicio(80,80) BEGIN INSPECT SYSIN DO
INSPECT SYSOUT DO
<program>
END
where "basicio" is defined by
CLASS basicio(sysinlength,sysoutlength);
INTEGER sysinlength,sysoutlength;
BEGIN REF(INFILE) PROCEDURE SYSIN;
SYSIN:- sysin;
REF(OUTFILE) PROCEDURE SYSOUT;
sysout:- sysout;
file CLASS INFILE;
file CLASS OUTFILE;
OUTFILE CLASS PRINTFILE;
file CLASS DIRECTFILE;
sysin :- NEW INFILE("SYSIN");
SYSIN.OPEN(BLANKS(sysinlength));) (1)
sysout :- NEW OUTFILE("SYSOUT");
SYSOUT.OPEN(BLANKS(sysoutlength)); (1)
INNER;
SYSIN.CLOSE;
SYSOUT.CLOSE;
END ***basicio*** ;
-----------------------------------------------------------
(1) The image length of sysin and sysout is device dependent, see
section 3.5.
DECSYSTEM-10 SIMULA LANGUAGE HANDBOOK, PART I Page 1000
APPENDIX C
index
-----
References in the index to the page number 1000 are to be
interpreted as references to parts II or III of the DECsystem-10
SIMULA Language Handbook.
!!! 5.0 Conversational terminals, use of more than one 269
!!! 5.0 HIBERNATE UUO of DECsystem-10 269
!!! 5.0 Multi-terminal system . . 269
!!! 5.0 Real time computer applications 269
!!! 5.0 Terminals, more than one used by the same program 269
!!! 5.0 TTY-s, more than one used by the same program 269
!!! 5.3 FORK statement . . . . . . 269
!!! 5.3 JOIN statement . . . . . . 269
!!! 5.3 Semaphore variables . . . 269
!!! 5.3.5 Industrial robot control 269
!!! 5.3.5 Process control applications 269
!!! 5.3.5 Robot control . . . . . 269
ABS function . . . . . . . . . . . 289
Access into a CLASS object . . . . 134-135, 156, 183-184
Access into a CLASS object (Simple introduction) 37
Accessible . . . . . . . . . . . . 189
Accessing . . . . . . . . . . . . 36
ACCUM . . . . . . . . . . . . . . 207
Activate . . . . . . . . . . . . . 207, 210
Activate statement, syntax and semantics 210
Activation statement (in table of statement kinds) 165
Activation statements (in table of statement kinds) 174
Active . . . . . . . . . . . . . . 56, 186
Actual parameter . . . . . . . . . 136
Actual parameter list . . . . . . 136
Actual parameter part . . . . . . 153
Actual parameter part in expression 153
Actual parameter when making NEW class objects 116
Actual parameter, correspondence with formal 114
Actual parameter, introduction . . 35
Actual parameter, redeclaration of 103
Actual parameter, transfer by name 109-110
Actual parameter, transfer by reference 107
Actual parameter, transfer by value 105
Actual parameter, transfer of . . 103
Actual-formal parameter correspondence 137
Addition sign (+) . . . . . . . . 71
Address of DECsystem-10 SIMULA maintenance 2
AFTER in the activate statement . 76, 210
Allocate of structure instances . 155, 185
Allocation of TEXT character strings 228
Alphabetic character . . . . . . . 68
Alphanumeric character . . . . . . 71
Alternatives . . . . . . . . . . . 66
ALTMODE character . . . . . . . . 282
Ampersand character (&) . . . . . 84
Ampersand character (&) . . . . . 282
AND . . . . . . . . . . . . . . . 26, 75, 147
ARCCOS function . . . . . . . . . 289
ARCSIN function . . . . . . . . . 289
ARCTAN function . . . . . . . . . 289
Argument to a procedure, see Parameter 103-104
Argument to an array . . . . . . . 135
Arguments to a CLASS . . . . . . . 113
Arithmetic constants . . . . . . . 84, 138
Arithmetic expression in assignment statement 169
Arithmetic expressions . . . . . . 131-132, 138
Arithmetic expressions, as array subscript 132, 135
Arithmetic expressions, syntax and semantics of 138
Arithmetic function designator . . 139
Arithmetic IF statement . . . . . 11
Arithmetic operator precedence . . 144
Arithmetic operators . . . . . . . 71, 138
Arithmetic operators and types . . 140
Arithmetic primary . . . . . . . . 138
Arithmetic type conversion . . . . 92
Arithmetic variable . . . . . . . 138
Arithmetics of (LONG)REAL quantities 140
ARRAY . . . . . . . . . . . . . . 17, 72, 94
ARRAY as a parameter . . . . . . . 100
ARRAY as CLASS attribute . . . . . 113
ARRAY bounds, exceeding of . . . . 135
ARRAY component . . . . . . . . . 94, 135
ARRAY declaration . . . . . . . . 94, 97
ARRAY dimension . . . . . . . . . 94
ARRAY identifier . . . . . . . . . 136
ARRAY initialization of . . . . . 94, 97
ARRAY segment . . . . . . . . . . 97
ARRAY, as CLASS parameter . . . . 113
ARRAY, three-dimensional . . . . . 96
ARRAY, two-dimensional . . . . . . 95
ASCII 7 bit character set . . . . 78, 280
Assembly language procedure . . . 124
Assembly language(MACRO 10) procedures, see part II 1000
Assignable range of variables, table 93
Assignable range, BOOLEAN . . . . 92
Assignable range, CHARACTER . . . 92
Assignable range, INTEGER . . . . 91
Assignable range, LONG REAL . . . 91
Assignable range, REAL . . . . . . 91
Assignable range, REF . . . . . . 92
Assignable range, SHORT INTEGER . 91
Assignable range, TEXT . . . . . . 92
Assignment . . . . . . . . . . . . 8, 132, 165-166
Asterisk (*) . . . . . . . . . . . 69
AT in the activate statement . . . 76, 210
Attached state . . . . . . . . . . 188
Attribute . . . . . . . . . . . . 37, 133
Attribute redefinition (VIRTUAL) . 116, 119-120
Attributes of CLASSes . . . . . . 114
Basic binding rules . . . . . . . 81
Basic concepts of SIMULA . . . . . 6
Basic symbol . . . . . . . . . . . 62, 64, 68, 71
Basic symbol set . . . . . . . . . 71
Basic symbols and syntactic variables 68
BASICIO . . . . . . . . . . . . . 237
Batch jobs, see part II . . . . . 1000
Becomes sign (:=) . . . . . . . . 73
BEFORE . . . . . . . . . . . . . . 76
BEFORE in the activate statement . 210
BEGIN . . . . . . . . . . . . . . 74
BEGIN (In CLASS declaration) . . . 112
BEGIN as start of a block . . . . 160
BEGIN as start of a compound statement 161
Bi-directional list . . . . . . . 195
Bibliography . . . . . . . . . . . 5
Binary constant . . . . . . . . . 87
Binary i/o, see part III . . . . . 1000
Binding rule . . . . . . . . . . . 13, 81
Binding rules, connection . . . . 184
Binding rules, remote accessing . 133
Binding rules, virtual quantities 120
Blank . . . . . . . . . . . . . . 220, 223
Blank character . . . . . . . . . 73
Blank, in CHARACTER constant . . . 87
Blank, in TEXT constant . . . . . 88
BLANKS, procedure for allocation of TEXTs 228
Block . . . . . . . . . . . . . . 11, 160, 163
Block head . . . . . . . . . . . . 89, 160
Block instance . . . . . . . . . . 13
Block prefix SIMSET . . . . . . . 195
Blocks and compound statements . . 160
Blocks and statements . . . . . . 160
BOOLEAN . . . . . . . . . . . . . 74, 91
BOOLEAN CLASS attribute . . . . . 111
BOOLEAN condition governing loop . 173
BOOLEAN expression . . . . . . . . 145
BOOLEAN function designator . . . 145
BOOLEAN operator . . . . . . . . . 145, 147
BOOLEAN primary . . . . . . . . . 145
BOOLEAN variable . . . . . . . . . 145
BOOLEAN, assignable range . . . . 93
Bounds of an array, exceeding of . 135
Bounds of ARRAY as CLASS attribute 113
Braces . . . . . . . . . . . . . . 65
Bracket, square ([ and ]) . . . . 72, 94
Brackets . . . . . . . . . . . . . 71
Branch on condition . . . . . . . 181
BREAKOUTIMAGE . . . . . . . . . . 245
Buffer . . . . . . . . . . . . . . 239
Built-in mathematical functions, type of 143
Call by NAME for procedures, table 104
Call by NAME of CLASS parameters (disallowed) 111
Call by NAME parameter in FOR statement 179
Call by NAME, disallowed to classes 104
Call by NAME, example of use . . . 101
Call by NAME, semantics . . . . . 109-110
Call by NAME, syntax of . . . . . 100
Call by reference for procedures, table 104
Call by reference of CLASS parameters 113
Call by reference, default . . . . 104
CALL by VALUE . . . . . . . . . . 100
CALL by VALUE for procedures, table 104
CALL by VALUE of CLASS parameters 113
CALL by VALUE, default . . . . . . 104
CALL of a CLASS object . . . . . . 114
Call of a subroutine . . . . . . . 180
CALL statement of FORTRAN and PL/I 180
CALL, procedure for attaching class objects 194
Calling a procedure . . . . . . . 180
CANCEL . . . . . . . . . . . . . . 207, 209
Car wash simulation . . . . . . . 53
Card reader . . . . . . . . . . . 255
Card source program input . . . . 80
CARRIAGE RETURN character . . . . 281
CASE statement, see INSPECT . . . 183
CASE statement, see SWITCH . . . . 98
CASE statement, see VIRTUAL procedures 119
Case, upper and lower . . . . . . 68
Catenation of TEXTs . . . . . . . 231
Chaining of items . . . . . . . . 195
CHAR PROCEDURE converts integer to character 292
CHARACTER . . . . . . . . . . . . 78, 91
CHARACTER access (to TEXTs) . . . 222
CHARACTER ARRAY . . . . . . . . . 220
CHARACTER as CLASS parameter . . . 111
CHARACTER constant . . . . . . . . 150
CHARACTER expression . . . . . . . 131, 150
CHARACTER function designator . . 150
CHARACTER quote (') . . . . . . . 72, 87
Character set . . . . . . . . . . 78, 280
CHARACTER string . . . . . . . . . 220
Character string memory allocation 228
Character string processing . . . 220
Character strings, concatenation of 231
CHARACTER to INTEGER conversion . 150
CHARACTER values, comparison . . . 148-149
CHARACTER variable . . . . . . . . 150
CHARACTER, assignable range . . . 93
CHARACTER, printable . . . . . . . 87
CHARACTER, upper and lower case of 68
CHARACTER-INTEGER conversion . . . 292
Circular list . . . . . . . . . . 195
CLASS . . . . . . . . . . . . . . 32, 74
CLASS (Simple introduction) . . . 32
CLASS attribute initialization . . 115
CLASS BASICIO . . . . . . . . . . 237
CLASS body . . . . . . . . . . . . 38, 89, 105, 107, 111-114, 118
CLASS body, generation of . . . . 155
CLASS body, protection of access to 125
CLASS declaration . . . . . . . . 36, 111
CLASS DIRECTFILE . . . . . . . . . 237-238, 252
CLASS entry points . . . . . . . . 120
CLASS FILE . . . . . . . . . . . . 237
CLASS HEAD . . . . . . . . . . . . 56, 195
CLASS HEAD in SIMSET . . . . . . . 195
CLASS hierarchies . . . . . . . . 117
CLASS identifier . . . . . . . . . 111
CLASS identifier as block prefix . 160
CLASS identifier in expression with IN or IS 148
CLASS identifier in NEW statement 153
CLASS INFILE . . . . . . . . . . . 237-238, 240
CLASS instance . . . . . . . . . . 111
CLASS LINK in SIMSET . . . . . . . 56, 195
CLASS LINKAGE in SIMSET . . . . . 195
CLASS object generation . . . . . 155, 185
CLASS OUTFILE . . . . . . . . . . 237, 244
CLASS parameters (table) . . . . . 113
CLASS PRINTFILE . . . . . . . . . 237, 247
CLASS PROCESS . . . . . . . . . . 56
CLASS SIMSET . . . . . . . . . . . 195
CLASS SIMSET, prefix to CLASS SIMULATION 206
CLASS SIMULATION . . . . . . . . . 56, 207
CLASS SIMULATION makes activation statements valid 174
CLASS specification part . . . . . 113
CLASS treatment . . . . . . . . . 215
CLOSE . . . . . . . . . . . . . . 238-241, 244, 247, 252-253, 257
Closed statements . . . . . . . . 165
Co-routine sequensing . . . . . . 191-192, 208
Collating sequence . . . . . . . . 78
Colon (:) . . . . . . . . . . . . 10, 69, 112
Colon (:) after label . . . . . . 165
Column 73-80 . . . . . . . . . . . 80
Column of input-output line = image.pos 238-239
Comma (,) . . . . . . . . . . . . 73
Comma (,) in array subscript list 132
Comma (,) in procedure call statement 180
Comma (,), use between subscripts 136
COMMENT . . . . . . . . . . . . . 23, 73
COMMON statement of FORTRAN . . . 259-260
Comparing operators . . . . . . . 146
Compile time . . . . . . . . . . . 7
Compile time and run time . . . . 7
Compile time error messages, see part II 1000
Compiler switches, see part II . . 1000
COMPLEX arithmetic . . . . . . . . 92
Compound statement . . . . . . . . 26, 160, 163
Compound tail . . . . . . . . . . 160
Concatenation of TEXTs . . . . . . 231
Concatenation of texts, see part III 1000
Condition . . . . . . . . . . . . 131, 139
Conditional branch . . . . . . . . 181
Conditional loop . . . . . . . . . 173
Conditional statement . . . . . . 9
Conditional statement, IF-THEN-ELSE ambiguity 163
Connection block . . . . . . . . . 158
Connection statement . . . . . . . 164, 183
Connection statement, syntax and semantics 183
Constants . . . . . . . . . . . . 83-88
Constants, arithmetic . . . . . . 84
Constants, binary . . . . . . . . 87
Constants, Boolean . . . . . . . . 87
Constants, character . . . . . . . 87
Constants, decimal . . . . . . . . 84
Constants, hexadecimal . . . . . . 87
Constants, integer . . . . . . . . 85
Constants, logical . . . . . . . . 87
Constants, octal . . . . . . . . . 87
Constants, reference . . . . . . . 88
Constants, text (=character string) 88
Constants, use in expression . . . 138
Constants, [long] real . . . . . . 85
Controlled statement . . . . . . . 174
Controlled variable . . . . . . . 175
Conversational i/o, see part III . 1000
Conversational terminal . . . . . 256
Conversational terminal, output to 238, 245, 247, 254-256
Conversion between CHARACTER and INTEGER 292
Conversion from INTEGER to CHARACTER 150
Conversion from numerical value to TEXT 234
Conversion from REAL to INTEGER . 290
Conversion from TEXT to numerical value 226, 232-233
COPY procedure for copying TEXTs . 220, 228
Copying of character strings (TEXTs) 228
COS function . . . . . . . . . . . 289
COSH function . . . . . . . . . . 290
CPU efficiency, procedure call versus class call 114
Creation of a new object . . . . . 155, 185
Critical regions . . . . . . . . . 194
CRT terminal, output to . . . . . 247
CURRENT in CLASS SIMULATION . . . 206-207
Data Base Handling, see part III . 1000
Data base handling, see part III . 1000
Data character set . . . . . . . . 71
Data collection . . . . . . . . . 212
Data set handling . . . . . . . . 237
De-editing procedures . . . . . . 223, 226, 232-233, 236
Debugging system (SIMDDT), see part II 1000
Decimal constant . . . . . . . . . 84-86
Decimal digit . . . . . . . . . . 68, 84
Declaration . . . . . . . . . . . 89
Declaration as part of a block . . 160
Declaration of a CLASS . . . . . . 111
Declarator . . . . . . . . . . . . 74
DECsystem-10 dependent parts of SIMULA, see part II 1000
Default action (AFTER/BEFORE) . . 211
Default action (AT/DELAY) . . . . 211
Default initial variable value (table) 92
Default mode of parameter transmission 104
Default value of a function designator 103
Defense Research Institute (Swedish) 2
Defining document of the SIMULA Language 5
DELAY in ACTIVATE statement . . . 76, 210
Delete character (Octal 177) . . . 84
Delete of TEXTs . . . . . . . . . 228
Deletion of CLASS objects . . . . 155
Delimiters . . . . . . . . . . . . 71
Denotes sign (:-) . . . . . . . . 73
Depending bounds of an ARRAY . . . 113
Designational expression . . . . . 98, 131, 151, 170
Destroy of CLASS objects . . . . . 155
Destroy of TEXTs . . . . . . . . . 228
DETACH (outside CLASS SIMULATION) 114, 155, 192
DETACH (outside CLASS SIMULATION), semantics 192
DETACH in CLASS SIMULATION . . . . 207
Detached state . . . . . . . . . . 155
Device control characters . . . . 71
Diagnostics from the SIMULA system, see part II 1000
Diagram . . . . . . . . . . . . . 31
Digit . . . . . . . . . . . . . . 232, 283
Digit in identifiers . . . . . . . 80
DIGIT, BOOLEAN PROCEDURE . . . . . 292
Digital constant in source program 85
Direct access file . . . . . . . . 252
Direct activation . . . . . . . . 210
DIRECTFILE . . . . . . . . . . . . 252, 303
DIRECTFILE, see part II . . . . . 1000
DISCRETE random drawing procedure 295
Display terminal, output to . . . 247
Divide (/) . . . . . . . . . . . . 69
DO . . . . . . . . . . . . . . . . 76
DO in FOR statement . . . . . . . 174-175
DO in INSPECT statement . . . . . 183
DO in WHILE statement . . . . . . 173
DO statement in FORTRAN . . . . . 174
DO statement in PL/I . . . . . . . 164
Dot (.) . . . . . . . . . . . . . 69
Dot (.) as decimal point . . . . . 84
Dot (.) preceding procedure call statement 180
Dot (.), for remote accessing into class objects 49, 133
Double quote (") . . . . . . . . . 282
Double quote inside TEXT constants 88
DRAW random drawing procedure . . 293
Dummy statement . . . . . . . . . 165, 170, 172
Dummy statement behaviour of INNER 119
Dummy statement instead of CLASS body 124
Dynamic memory allocation . . . . 155
Dynamic memory allocation, introduction 36
E, exponent sign . . . . . . . . . 235
EBCDIC character set . . . . . . . 78, 280
EDITed input . . . . . . . . . . . 240
EDITed output . . . . . . . . . . 244
Editing of SIMULA source programs, see part II 1000
Editing procedures . . . . . . . . 232, 234
Efficiency of quasi-parallel processing 114
Efficiency, procedure call versus class call 114
EJECT . . . . . . . . . . . . . . 247-248
Element oriented i/o . . . . . . . 243
Element oriented input . . . . . . 240
Element oriented output . . . . . 244
ELSE . . . . . . . . . . . . . . . 76, 138
ELSE in object expression . . . . 153
ELSE, with character expression . 150
Empty part and VIRTUAL part . . . 113
Empty TEXT value (NOTEXT) . . . . 77
END . . . . . . . . . . . . . . . 79, 161
END in CLASS declaration . . . . . 112
END of a block . . . . . . . . . . 160
END of a compound statement . . . 161
End of file . . . . . . . . . . . 240-241
End of file condition: procedure LASTITEM 240-243, 252
ENDFILE . . . . . . . . . . . . . 240-241
ENTIER function . . . . . . . . . 290
Entry points into a subroutine . . 120
EQ (=) . . . . . . . . . . . . . . 72, 146
Equal to sign (=) . . . . . . . . 69, 72
Equivalence (EQV) Boolean (logical) operator 75
Equivalence = shared storage, use garbage collector 155
Equivalence of TEXTs, see Subtext 225
EQV . . . . . . . . . . . . . . . 75, 147
ERLANG random drawing procedure . 294
Error messages, see part II . . . 1000
Error report form, see part II . . 1000
Event generation in CLASS SIMULATION 208-209
Event in CLASS SIMULATION . . . . 206
Event notice in CLASS SIMULATION . 206
Evtime in CLASS SIMULATION . . . . 206, 208
Examples . . . . . . . . . . . . . 6
Exclamation mark (!) . . . . . . . 73
Exit from a block . . . . . . . . 89
EXP function . . . . . . . . . . . 289
Exponent sign (&) . . . . . . . . 69
Exponent sign (&) . . . . . . . . 84
Exponent sign in decimal constant 84
Exponent, in [LONG] REAL constant 84
Expression . . . . . . . . . . . . 131, 136
Expression in assignment statement 166
EXTERNAL CLASS . . . . . . . . . . 261-263
EXTERNAL CLASS, see part II . . . 1000
External data . . . . . . . . . . 237-238
EXTERNAL declaration . . . . . . . 124
External file . . . . . . . . . . 237
EXTERNAL PROCEDURE . . . . . . . . 261, 263
EXTERNAL PROCEDURE, see part II . 1000
External record . . . . . . . . . 237
FALSE . . . . . . . . . . . . . . 77, 87, 145
Field . . . . . . . . . . . . . . 242, 246
Figure . . . . . . . . . . . . . . 31
File . . . . . . . . . . . . . . . 237
File handling . . . . . . . . . . 237
File handling, DEC 10 dependent parts, see part II 1000
File handling, direct random access 252
File name . . . . . . . . . . . . 238
First value of CLASS attributes . 115
Fixed field text editing . . . . . 235
Floating point constant . . . . . 84-85
Floating point expressions . . . . 140-142
Floating point value range . . . . 93
FOA . . . . . . . . . . . . . . . 2
FOLLOW in SIMSET . . . . . . . . . 196, 200
FOR . . . . . . . . . . . . . . . 76
FOR list element . . . . . . . . . 176
FOR statement . . . . . . . . . . 12, 174
FOR statement and local labels . . 179
FOR statement, ambiguity with . . 164
FOR statement, restrictions on, see part II 1000
FORM FEED character . . . . . . . 71, 281
Formal parameter . . . . . . . . . 81
Formal parameter part . . . . . . 109
Formal-actual parameter correspondence 137
Formalism of syntax description in this manual 62
FORMAT statement of FORTRAN . . . 233-234
FORMATted input . . . . . . . . . 240
FORMATted output . . . . . . . . . 244
FORTRAN subroutine called from SIMULA 124
FORTRAN subroutine called from SIMULA, see part II 1000
FREE of storage . . . . . . . . . 155
Free on TEXTs . . . . . . . . . . 228
Function . . . . . . . . . . . . . 99
Function declaration . . . . . . . 99
Function designator . . . . . . . 131, 136, 153
Garbage collection of TEXTs . . . 228
Garbage collector . . . . . . . . 155
GE (>=) . . . . . . . . . . . . . 72, 146
Generated object . . . . . . . . . 155
Generation of new class objects . 155, 185
Generation of TEXT character strings 228
Geometrical application . . . . . 31
GETCHAR . . . . . . . . . . . . . 226
GETFRAC . . . . . . . . . . . . . 234
GETINT . . . . . . . . . . . . . . 234
GETREAL . . . . . . . . . . . . . 234
GO TO . . . . . . . . . . . . . . 170
GO TO exit . . . . . . . . . . . . 114, 189
GO TO statement . . . . . . . . . 9, 76, 170, 189
GO TO, assigned . . . . . . . . . 98
GO TO, computed . . . . . . . . . 98
Graphic terminal handling, see part III 1000
Graphical applictions . . . . . . 31
Greater than (>) . . . . . . . . . 69, 72, 146
Greater than on characters . . . . 78
Greater than or equal to sign (>=) 72
Group markers . . . . . . . . . . 234
Grouped item . . . . . . . . . . . 234
GT (>) . . . . . . . . . . . . . . 72, 146
Hardware representation, see part II 1000
HEAD in SIMSET . . . . . . . . . . 195-196, 199
Heap memory . . . . . . . . . . . 155
Hexadecimal constant . . . . . . . 87
HIDDEN PROTECTED protection feature 125
HIDDEN specification . . . . . . . 125
HIDDEN, syntax . . . . . . . . . . 75
HISTD random drawing procedure . . 296
HOLD in CLASS SIMULATION . . . . . 206-207, 209
Hyperbolic functions . . . . . . . 290
i/o, see Input-output . . . . . . 237
IBM 360/370 type compatibility with 91
Identifier . . . . . . . . . . . . 68, 89, 189
Identifier clash . . . . . . . . . 137, 189
Identifier list . . . . . . . . . 91, 100, 111
Identifier, with upper and lower case letters in 68
Identifiers and key words . . . . 81
Idle in CLASS SIMULATION . . . . . 208
IF . . . . . . . . . . . . . . . . 76
IF clause . . . . . . . . . . . . 131, 138-140, 145, 150, 158
IF clause . . . . . . . . . . . . 181
IF clause example of use in expression 139
IF clause in object expression . . 154
IF clause in text expression . . . 159
IF clause, with character expression 150
IF statement . . . . . . . . . . . 181
IF statement, ambiguity with . . . 163
IFIX function . . . . . . . . . . 290
IMAGE . . . . . . . . . . . . . . 238-245
IMAGE size for SYSIN and SYSOUT . 254
IMP . . . . . . . . . . . . . . . 75, 147
Implication (IMP) Boolean operator 75, 147
IN . . . . . . . . . . . . . . . . 77, 148
INCHAR . . . . . . . . . . . . . . 240-242, 252
INCLUDED CLASSes of prefixing CLASSes 118
Index to an array . . . . . . . . 135
INFILE . . . . . . . . . . . . . . 237, 240, 254, 302
INFILE, see part II . . . . . . . 1000
INFRAC . . . . . . . . . . . . . . 240-241, 243, 252
INIMAGE . . . . . . . . . . . . . 240-241, 252
ININT . . . . . . . . . . . . . . 240
Initial value for each variable type (table) 92-93
Initial value of CLASS attributes. 115
Initial value, introduction . . . 11
Initial value, type dependency of 83
Initialization of CLASS attributes. 115
INNER . . . . . . . . . . . . . . 76, 107, 112, 118-119, 122
INNER accesibility (VIRTUAL) . . . 119
Inner block . . . . . . . . . . . 22
INNER levels, access by connection statement 184
INNER, example with protection . . 129
INNER, use in BASICIO . . . . . . 254, 257
Input from TTY, IMAGE size (Line length) 254
Input, formatted . . . . . . . . . 240
Input-output . . . . . . . . . . . 237
Input-output, DEC 10 dependent parts, see part II 1000
Input-output, element oriented . . 243
input-output, non-formatted, binary, see part III 1000
input-output, record oriented . . 241
Input-output, record oriented, see part III 1000
INREAL . . . . . . . . . . . . . . 240-241, 243, 252, 256
INSPECT . . . . . . . . . . . . . 52, 76, 164, 183
INSPECT syntax and semantics . . . 183
Instantaneous qualification . . . 158
INT function . . . . . . . . . . . 290
INTEGER . . . . . . . . . . . . . 74, 85, 91
INTEGER as CLASS attributes . . . 111
INTEGER constant . . . . . . . . . 85
INTEGER declaration . . . . . . . 91
INTEGER division sign (//) . . . . 71
INTEGER from REAL conversion . . . 290
INTEGER in expressions . . . . . . 140
INTEGER item . . . . . . . . . . . 235
INTEGER, assignable range . . . . 93
INTEGER-CHARACTER conversion . . . 150, 292
INTEXT . . . . . . . . . . . . . . 240-242, 252, 256
INTO in SIMSET . . . . . . . . . . 196, 200
IS . . . . . . . . . . . . . . . . 77, 148
ISO 7 bit character set . . . . . 78, 280
Iteration statement . . . . . . . 174
Jump on condition . . . . . . . . 181
Jump statement . . . . . . . . . . 170
Jump statement, variable, computed, assigned 98
Key word . . . . . . . . . . . . . 62, 71
Key word constant . . . . . . . . 71
Kill of TEXTs . . . . . . . . . . 228
Label . . . . . . . . . . . . . . 73, 100, 165, 170
Label as formal parameter . . . . 81
Label before END . . . . . . . . . 172
Label identifier . . . . . . . . . 136, 151
Label in front of FOR-statement . 175
Label inside a procedure . . . . . 103
Label, as procedure parameter . . 105
Label, as procedure parameter by reference 107
Label, as procedure parameter, table 104
Label, hiding of . . . . . . . . . 129
Label, local to a FOR statement . 171
Label, variable . . . . . . . . . 98
Label, virtual . . . . . . . . . . 112
Language character set . . . . . . 68, 71
Language used in this manual . . . 62
LASTITEM . . . . . . . . . . . . . 240-243, 252
LE (<=) . . . . . . . . . . . . . 72, 146
Left parenthesis (() . . . . . . . 78, 94, 111, 151
Left parenthesis (() in expression 138
Left parenthesis ((), use in CLASS declaration 111
Left square bracket . . . . . . . 94
LENGTH . . . . . . . . . . . . . . 224
LENGTH of a file image . . . . . . 238
LENGTH of a TEXT . . . . . . . . . 220
Length of a text value . . . . . . 224
Length of identifiers . . . . . . 81
Length of input lines, SYSIN from TTY 254
Length of output lines, SYSOUT to TTY 254
Less than on characters . . . . . 78
Less than or equal to sign (<=) . 72
Less than sign (<) . . . . . . . . 72
Letter . . . . . . . . . . . . . . 282
Letter in identifier . . . . . . . 80
LETTER, BOOLEAN PROCEDURE . . . . 292
Letter, Swedish . . . . . . . . . 68
Letter, upper and lower case of . 68
Line . . . . . . . . . . . . . . . 238-240
LINE FEED character . . . . . . . 280
Line in input or output . . . . . 240-245
Line length . . . . . . . . . . . 80
Line number generation . . . . . . 280-281
Line numbered source program files, see part II 1000
Line printer . . . . . . . . . . . 247-248, 255
LINEAR random drawing procedure . 295
Linelength . . . . . . . . . . . . 238-239
Linelength, default value for SYSIN and SYSOUT 254
LINESPERPAGE . . . . . . . . . . . 247
LINK in SIMSET . . . . . . . . . . 195, 200
LINKAGE in SIMSET . . . . . . . . 195, 197
Linked lists of items . . . . . . 195
Linking of TEXTs . . . . . . . . . 231
List processing . . . . . . . . . 195
List processing (Simple introduction) 40
Listing of program, division into pages 281
Literal constants . . . . . . . . 83-88
Litterature . . . . . . . . . . . 5
LN function . . . . . . . . . . . 290
Local object . . . . . . . . . . . 158
Local quantity in a block . . . . 161
Local sequence control (LSC) . . . 191
LOCATE . . . . . . . . . . . . . . 252-253
Location . . . . . . . . . . . . . 252
Logarithm . . . . . . . . . . . . 290
Logical AND . . . . . . . . . . . 75
Logical condition governing loop . 173
Logical equivalence (EQV) . . . . 75
Logical expression . . . . . . . . 145
Logical IF statement . . . . . . . 181
Logical implication (IMP) . . . . 75
Logical inclusive or (OR) . . . . 75
Logical negation (NOT, \) . . . . 71
Logical operator . . . . . . . . . 71, 145
LONG REAL . . . . . . . . . . . . 73
LONG REAL as CLASS attribute . . . 111
LONG REAL constant . . . . . . . . 84-85
LONG REAL declaration . . . . . . 91
LONG REAL in expression . . . . . 140
LONG REAL, assignable range . . . 91, 93
LONG REAL, availability of functions in 290
LONG REAL, syntax . . . . . . . . 91
Loop statement . . . . . . . . . . 174
Loop, conditional . . . . . . . . 173
Lower bound . . . . . . . . . . . 94
Lower case characters . . . . . . 68
Lower subscript bound . . . . . . 94
LOWTEN . . . . . . . . . . . . . . 233, 296
LSC . . . . . . . . . . . . . . . 191
LT (<) . . . . . . . . . . . . . . 72, 146
MACRO 10 procedure called from SIMULA program 124
MACRO 10 procedure called from SIMULA, see part II 1000
Mailing list for users of DECsystem-10 SIMULA 2
Main block = part of block after prefix 160
MAIN in CLASS SIMULATION . . . . . 206-207, 209
MAIN of TEXTs . . . . . . . . . . 224
Main part of CLASS declaration . . 111
Manuals, list of . . . . . . . . . 5
Matching attribute (VIRTUAL) . . . 123
Matching qualification . . . . . . 107
Mathematical functions . . . . . . 289
Mathematical functions, type of . 143
Matrix handling . . . . . . . . . 95
Maximum value of variables, table 93
Memory allocation for TEXT character strings 228
Metalanguage in this manual . . . 62
Minimum value of variables, table 93
Minus (-) . . . . . . . . . . . . 71
MOD function . . . . . . . . . . . 290
Mode part . . . . . . . . . . . . 99
Modulo function . . . . . . . . . 290
MORE . . . . . . . . . . . . . . . 222, 226, 246
Multi-terminal applications, see part III 1000
Multiple assignment . . . . . . . 25
Multiplication sign (*) . . . . . 71
NAME parameter to a CLASS (disallowed) 111
NAME parameter transmission, introduction 39
NAME parameter transmission, semantics 109-110
NAME parameters for procedures, table 104
NAME parameters to classes disallowed 104
NAME, example of use . . . . . . . 101
NAME, syntax . . . . . . . . . . . 75
NAME, syntax of . . . . . . . . . 100
National character . . . . . . . . 68, 282, 284, 286-288
National Defense Research Institute (Swedish) 2
NE (\=) . . . . . . . . . . . . . 146
NE (\=) . . . . . . . . . . . . . 72
NEGEXP random drawing procedure . 294
NEW (Example) . . . . . . . . . . 49
NEW (Simple introduction) . . . . 36
NEW operator, parameter correspondence to 114
NEW operator, semantics . . . . . 155
NEW operator, table of parameter transmission 113
NEW statement, semantics . . . . . 185
NEW TEXT generation . . . . . . . 228
NEW, syntax . . . . . . . . . . . 77, 153
Newsletter on SIMULA . . . . . . . 5
Nextev in CLASS SIMULATION . . . . 208
Non-empty prefix and empty virtual part 116
Non-formatted i/o, see part III . 1000
NONE . . . . . . . . . . . . . . . 37, 77, 88, 153
NONE in object expression . . . . 153
NORMAL random drawing procedure . 293
Norwegian Computing Centre . . . . 5
NOT (\) . . . . . . . . . . . . . 146
NOT (\) . . . . . . . . . . . . . 71
NOT (\) . . . . . . . . . . . . . 71
NOT EQUAL TO SIGN (\=) . . . . . . 72
NOT EQUAL TO SIGN (\=) . . . . . . 70
Notation used in this manual . . . 62
NOTEXT . . . . . . . . . . . . . . 77, 220
NOTEXT in TEXT expression . . . . 159
NOTEXT, POS of . . . . . . . . . . 226
NOTEXT, use of to make a TEXT wholly blank 227
Null character (Octal 177) . . . . 84
Null character (Octal zero) . . . 84
Number constant in source program 85
Number systems . . . . . . . . . . 87
Number, binary, octal or hexadecimal 87
Number, decimal . . . . . . . . . 84
Number, integer . . . . . . . . . 85
Number, [LONG] REAL . . . . . . . 84
Numeric item . . . . . . . . . . . 233-234
Numeric text values . . . . . . . 233-234
Numerical value to TEXT conversion 234
Numerical value, conversion from TEXT 233
Object . . . . . . . . . . . . . . 153
Object element . . . . . . . . . . 175
Object expression . . . . . . . . 131-133, 148, 153-154, 176
Object expression, syntax and semantics of 153
Object generator . . . . . . . . . 153, 185
Object in expression . . . . . . . 153
Object of a CLASS . . . . . . . . 111
Object program . . . . . . . . . . 7
Object-time error messages, see part II 1000
Octal constant . . . . . . . . . . 87
One dimensional array . . . . . . 94
Open . . . . . . . . . . . . . . . 240
Open statement . . . . . . . . . . 165
Operand . . . . . . . . . . . . . 131, 141-142
Operator . . . . . . . . . . . . . 71, 131, 138, 140, 144
Operator word . . . . . . . . . . 71
OPTIONS statement . . . . . . . . 74
OPTIONS statement, see part II . . 1000
OR . . . . . . . . . . . . . . . . 26, 75, 147
OTHERWISE . . . . . . . . . . . . 76, 183-184
OUT in SIMSET . . . . . . . . . . 200
OUTCHAR . . . . . . . . . . . . . 244, 246, 252
Outer block . . . . . . . . . . . 22
OUTER CLASS declarations . . . . . 118
OUTFILE . . . . . . . . . . . . . 237, 244, 302
OUTFILE, see part II . . . . . . . 1000
OUTFIX . . . . . . . . . . . . . . 244, 246, 252
OUTFRAC . . . . . . . . . . . . . 244, 246, 252
OUTINT . . . . . . . . . . . . . . 244, 246, 252, 256
Output statistics collection . . . 212
Output, formatted . . . . . . . . 244
OUTREAL . . . . . . . . . . . . . 246, 252, 256
OUTTEXT, example of use . . . . . 101
Packing and unpacking into parts of words, see part III 1000
Pages, division of program listing into 281
Parallel processing of vectors . . 174
Parallel processing with implicit time axis 208
Parallel processing without implicit time axis 191-192
Parameter part of CLASS declaration 111
Parameter to a CLASS . . . . . . . 113
Parameter to a PROCEDURE . . . . . 99
Parameter transmission . . . . . . 104
Parameter transmission modes to classes 104
Parameter transmission to a procedure 103
Parameters to a procedure . . . . 104
Parenthesis, square ([ and ]) . . 72
Parenthesises (( and )) . . . . . 94, 283
Parenthesises, square ([ and ]) . 94
Part-compilation . . . . . . . . . 258
Part-compilation, see part II . . 1000
PASSIVATE in CLASS SIMULATION . . 206-207, 209
Passive . . . . . . . . . . . . . 56, 191
Period (.) . . . . . . . . . . . . 69
PICTURE statement of COBOL . . . . 233
Plotting . . . . . . . . . . . . . 31
Plotting, see part III . . . . . . 1000
Plus (+) . . . . . . . . . . . . . 71
Pointer variable, use of . . . . . 133, 183-184
Pointer variable, use of in expression 153
POISSON random drawing procedure . 294
POS . . . . . . . . . . . . . . . 223, 226
POS of a file image . . . . . . . 244
Power sign (** or ^) . . . . . . . 71
PRECEDE in SIMSET . . . . . . . . 200
Precedence of operators . . . . . 147
Precision of variables, table . . 93
PRED in SIMSET . . . . . . . . . . 195-197
Prefix chain of CLASS declarations 117
Prefix sequence . . . . . . . . . 41, 162
Prefixed block . . . . . . . . . . 52, 160
PREV in SIMSET . . . . . . . . . . 197-198
Primer on SIMULA . . . . . . . . . 5
Printable character . . . . . . . 87
PRINTFILE . . . . . . . . . . . . 237, 247, 254, 303
PRINTFILE, see part II . . . . . . 1000
PRIOR in activate statement . . . 76, 210
PROCEDURE . . . . . . . . . . . . 38, 73, 99
PROCEDURE as CLASS attribute . . . 112, 114
PROCEDURE body . . . . . . . . . . 39, 82, 99
PROCEDURE call, efficiency of . . 114
PROCEDURE CHAR . . . . . . . . . . 150
PROCEDURE COMPRESS . . . . . . . . 227
PROCEDURE declaration . . . . . . 38, 99
PROCEDURE declaration in outermost CLASS body 112
PROCEDURE DIGIT . . . . . . . . . 150
PROCEDURE FACTORIAL (INTEGER) . . 102
PROCEDURE heading . . . . . . . . 99
PROCEDURE identifier . . . . . . . 99, 136
PROCEDURE LETTER . . . . . . . . . 150
PROCEDURE NORM (REAL) . . . . . . 102
PROCEDURE NULLREF (INTEGER) . . . 107
PROCEDURE OUTCOLUMN . . . . . . . 101
PROCEDURE parameter transmission . 103
PROCEDURE parameters . . . . . . . 104-105
PROCEDURE parameters (table) . . . 104
PROCEDURE PLACE . . . . . . . . . 203-204
PROCEDURE RANK . . . . . . . . . . 150
PROCEDURE SELECT . . . . . . . . . 203-204
PROCEDURE statement . . . . . . . 180
PROCEDURE TREETRAVERSE . . . . . . 101
PROCEDURE, call by value . . . . . 100
PROCEDURE, return from . . . . . . 103
PROCESS (Introduction) . . . . . . 56
Process control applications, see part III 1000
PROCESS expression . . . . . . . . 210
PROCESS in CLASS SIMULATION . . . 206-208
PROCESS object (table of states) . 206-210
Program . . . . . . . . . . . . . 160
Program = block or compound statement 160
Program content . . . . . . . . . 68
Program library, see part III . . 1000
Program sequence control . . . . . 186
Program structure . . . . . . . . 186
Proper PROCEDURE declaration . . . 99
PROTECTED protection feature . . . 125
PROTECTED, syntax . . . . . . . . 75
Protection . . . . . . . . . . . . 125
PSC . . . . . . . . . . . . . . . 186
Punched card source program input 80
PUTCHAR . . . . . . . . . . . . . 222
PUTFIX . . . . . . . . . . . . . . 235, 246
PUTINT . . . . . . . . . . . . . . 235
PUTREAL . . . . . . . . . . . . . 235, 246
QUA, example of use . . . . . . . 134, 153
QUA, qualification of result . . . 154
QUA, semantics . . . . . . . . . . 156
QUA, syntax . . . . . . . . . . . 77, 153
Qualification . . . . . . . . . . 37
Qualification error . . . . . . . 168
Qualification in object expression 153
Qualification of actual parameter 107
Qualifying CLASS . . . . . . . . . 92
Quantity . . . . . . . . . . . . . 93
Quasi-parallel processing with implicit time axis 208
Quasi-parallel processing without implicit time axis 191-192
Quasi-parallel processing, efficiency of 114
Quasi-parallel system, definition by a prefixed block 162
Quote, double (") . . . . . . . . 282
Quote, double, inside TEXT constants 88
Quote, single (') . . . . . . . . 283
Radix . . . . . . . . . . . . . . 87
Raised to the power of sign (** or ^) 71
RANDINT random drawing procedure . 293
Random access to disk file records 252
Random access to disk file records, see part II and III 1000
Random drawing procedures . . . . 293
Range of values, BOOLEAN variable 92
Range of values, CHARACTER variable 92
Range of values, INTEGER constant 85
Range of values, INTEGER variable 91
Range of values, LONG REAL constant 86
Range of values, LONG REAL variable 91
Range of values, REAL constant . . 86
Range of values, REAL variable . . 91
Range of values, REF variable . . 92
Range of values, SHORT INTEGER constant 85
Range of values, SHORT INTEGER variable 91
Range of values, TEXT variable . . 92
Range of variables, table of . . . 93
RANK . . . . . . . . . . . . . . . 149-151
RANK, INTEGER PROCEDURE . . . . . 292
REACTIVATE in CLASS SIMULATION . . 76, 206, 210
REAL . . . . . . . . . . . . . . . 73, 91
REAL constant . . . . . . . . . . 84-85
REAL declaration . . . . . . . . . 91
REAL in expression . . . . . . . . 140
REAL item . . . . . . . . . . . . 235
Real time applications with many terminals, see part III 1000
REAL to INTEGER conversion . . . . 290
REAL, as CLASS attribute . . . . . 111
REAL, assignable range . . . . . . 91, 93
Record . . . . . . . . . . . . . . 238-240
Record declaration . . . . . . . . 111
Record oriented i/o, see part III 1000
Record oriented input . . . . . . 240-241
Record oriented output . . . . . . 244
Recursion . . . . . . . . . . . . 103
Redefines = shared storage, use garbage collector 155
Redefines on TEXTs, see Subtext . 225
REF . . . . . . . . . . . . . . . 74, 83, 91
REF parameters to separately compiled PROCEDURES 266
REF variable, assignable range . . 93
REF variables, use of (Simple introduction) 32
REF variables, use of to access into CLASS objects 133, 183-184
REF, as CLASS attribute . . . . . 111
Reference assignment . . . . . . . 166, 168
Reference comparator . . . . . . . 71
Reference comparator, main treatment of 148
Reference equal (==) . . . . . . . 72, 146-148, 157
Reference equal (==), main treatment of 148
Reference not equal (=/=) . . . . 72, 146, 148
Reference type . . . . . . . . . . 83
Reference variable . . . . . . . . 32
Reference variable, use of in expression 153
Reference variables (Simple introduction) 32
Reference variables, use of for accessing data 183-184
References (= Bibliography) . . . 5
Relation . . . . . . . . . . . . . 145-147
Relational operator . . . . . . . 71
Remainder at division, function for 290
Remote accessing . . . . . . . . . 37, 133, 183-184
Remote identifier . . . . . . . . 136
Remote-variable . . . . . . . . . 132
Removal of CLASS objects . . . . . 155
Removal of TEXTs . . . . . . . . . 228
Repetition . . . . . . . . . . . . 67, 174
Repetition, conditional . . . . . 173
Reserved word . . . . . . . . . . 74
Reserved words (table) see part II 1000
Restrictions in the DEC 10 SIMULA system, see part II 1000
RESUME in CLASS SIMULATION . . . . 206-207
RESUME procedure operating on class instances 114, 191
RESUME, semantics . . . . . . . . 191-192
RETURN from a CLASS execution . . 192
RETURN from a subroutine . . . . . 103
RETURN value from a procedure . . 39
Right parenthesis ()) . . . . . . 78, 94, 111, 151
Right parenthesis ()) in expression 138
Right parenthesis ()), use in CLASS declaration 111
Right square bracket . . . . . . . 94
RTS block . . . . . . . . . . . . 28
RTS info . . . . . . . . . . . . . 13, 35
Run time . . . . . . . . . . . . . 7
Run time error . . . . . . . . . . 37, 240-243, 247
Run time structure . . . . . . . . 186
Run time system . . . . . . . . . 7
Run time system information . . . 13
Run-time error messages, see part II 1000
Safe conversational i/o, see part III 1000
Scheduling with implicit time axis 208
Scheduling without implicit time axis 191-192
Scope . . . . . . . . . . . . . . 81-82
Security . . . . . . . . . . . . . 37, 119, 125
Security although separate compilation 259
Security by module protection . . 125
Segmentation into separately compiled modules 258
Segmentation of programs . . . . . 125
Semantics . . . . . . . . . . . . 62
Semaphore variables . . . . . . . 194
Semicolon (;) . . . . . . . . . . 10, 73, 99
Separate compilation . . . . . . . 258
Separate compilation, External declaration 124
Separate compilation, see part II 1000
Separator . . . . . . . . . . . . 71
Sequential file organisation . . . 237
Sequential operator . . . . . . . 75
Set handling . . . . . . . . . . . 195
SETPOS on file objects . . . . . . 238-239, 257
SETPOS on TEXTs . . . . . . . . . 223, 226
Shared storage . . . . . . . . . . 155
SHORT INTEGER . . . . . . . . . . 74, 83, 91
SHORT INTEGER constant . . . . . . 83
SHORT INTEGER in expression . . . 140
SHORT INTEGER, as CLASS attribute 111
SHORT INTEGER, assignable range . 93
SIGN function . . . . . . . . . . 290
Sign part . . . . . . . . . . . . 233
SIMDDT (Debugging system), see part II 1000
Simple arithmetic expression . . . 138
Simple character expression . . . 150
Simple designational expression . 151
Simple object expression . . . . . 133, 148, 180
Simple reference expression in relation 146
Simple TEXT expression . . . . . . 132, 158
Simple value expression in realtion 146
Simple variable . . . . . . . . . 132, 176
SIMSET . . . . . . . . . . . . . . 195, 297
SIMSET and separately compiled CLASS-es 267
SIMSET, prefix to SIMULATION . . . 207
SIMULA Language standard definition 5
SIMULA maintenance on DECsystem-10, address 2
SIMULA newsletter . . . . . . . . 5
SIMULA on DECsystem-10, how to get info on updates 2
SIMULATION . . . . . . . . . . . . 297
SIMULATION and separately compiled CLASS-es 267-268
Simulation capabilities of SIMULA (Introduction) 53
SIMULATION, a SIMULA CLASS (Introduction) 56
Simulation, example of . . . . . . 214
SIN function . . . . . . . . . . . 290
SIN function, type of . . . . . . 143
Single quote (') . . . . . . . . . 283
SINH function . . . . . . . . . . 290
Sinus function . . . . . . . . . . 139
SKIP PAGE, see EJECT . . . . . . . 247
Sorting order of characters . . . 78
Source program . . . . . . . . . . 7
Source program line length . . . . 80
Space character . . . . . . . . . 73
SPACING . . . . . . . . . . . . . 247-248
SPEC part . . . . . . . . . . . . 100
Special character . . . . . . . . 62, 71
Specificator . . . . . . . . . . . 74
Split body . . . . . . . . . . . . 112
SQRT function . . . . . . . . . . 290
Square bracket ([ and ]) . . . . . 66, 72, 94
Square root function . . . . . . . 290
Square root function, type of . . 143
Stack . . . . . . . . . . . . . . 40
Stack of attached blocks . . . . . 188
Stack of blocks . . . . . . . . . 188
Standard system PROCEDURES . . . . 30
Standardization of SIMULA . . . . 5
Start value of CLASS attributes . 115
Statement . . . . . . . . . . . . 8, 163
Statement bracket . . . . . . . . 74
Statement number, variable . . . . 98
Statement, compound or block . . . 160
Statements, table of allowed kinds of 165
Statistics collection . . . . . . 212
STEP . . . . . . . . . . . . . . . 76, 175
Storage reorganisation . . . . . . 155
String of characters, concatenation of 231
String of characters, memory allocation for 228
String processing . . . . . . . . 220
STRIP . . . . . . . . . . . . . . 225
Structure declaration . . . . . . 111
SUB . . . . . . . . . . . . . . . 221, 225
Subclass . . . . . . . . . . . . . 92, 116, 118, 120, 123
Subclass, protection against . . . 126
Subroutine . . . . . . . . . . . . 99
Subroutine entry points . . . . . 120
Subscript . . . . . . . . . . . . 132-133, 135
Subscript bound . . . . . . . . . 94, 135
Subscript bounds of CLASS attribute 113
Subscript list . . . . . . . . . . 132
Subscript of SWITCH . . . . . . . 151
Subscripted variable . . . . . . . 94
Subtexts . . . . . . . . . . . . . 225
Subtraction, sign (-) . . . . . . 71
SUC in SIMSET . . . . . . . . . . 195-197
Swedish Defense Research Institute 2
Swedish letter . . . . . . . . . . 68, 282, 284, 286-288
SWITCH . . . . . . . . . . . . . . 74
SWITCH declaration . . . . . . . . 98
SWITCH designator . . . . . . . . 98
SWITCH identifier . . . . . . . . 98, 136, 151
SWITCH list . . . . . . . . . . . 98
SWITCH, as CLASS attribute . . . . 112
SWITCH, as PROCEDURE parameter . . 100
Switches to the compiler . . . . . 74
Switches to the compiler, see part II 1000
Syntactic unit . . . . . . . . . . 63, 65
Syntactic variable . . . . . . . . 62
Syntactical description language in this manual 62
Syntax . . . . . . . . . . . . . . 62
SYSIN . . . . . . . . . . . . . . 254-256
SYSIN, IMAGE size . . . . . . . . 254
SYSOUT . . . . . . . . . . . . . . 254-257
TAB character . . . . . . . . . . 71, 280
TAN function . . . . . . . . . . . 290
TAN function, type of . . . . . . 143
TANH function . . . . . . . . . . 290
Terminated . . . . . . . . . . . . 155, 191
Terminated in CLASS SIMULATION . . 208-209
TEXT . . . . . . . . . . . . . . . 74, 91, 220, 237, 240-242, 244
TEXT assignment . . . . . . . . . 220
TEXT constant containing double quote (") 88
TEXT constant in TEXT expression . 159
TEXT editing and de-editing . . . 223
Text editing of SIMULA source programs, see part II 1000
TEXT expression . . . . . . . . . 131-132, 135, 158-159
TEXT expression and TEXT value . . 159
TEXT expression, syntax and semantics of 158
TEXT function designator . . . . . 159, 167
TEXT generation . . . . . . . . . 228
TEXT handling . . . . . . . . . . 220
Text handling utility package, see part III 1000
TEXT object . . . . . . . . . . . 220
TEXT quote (") . . . . . . . . . . 69, 88
TEXT reference assignment . . . . 221
TEXT reference, comparison of . . 148
TEXT to numerical value conversion 233
TEXT value . . . . . . . . . . . . 131, 159, 220
TEXT value assignment . . . . . . 166, 226
TEXT value, conversion from numerical 234
TEXT values, comparison of . . . . 148
TEXT variable . . . . . . . . . . 159, 220
TEXT variable, assignable range . 93
TEXT, as CLASS attribute . . . . . 111
TEXT, output of . . . . . . . . . 245
Textbook on SIMULA . . . . . . . . 5
TEXTs with variable length . . . . 231
TEXTs, concatenation of . . . . . 231
Textual link . . . . . . . . . . . 29
THEN . . . . . . . . . . . . . . . 76, 131, 163
THEN, ambiguity after . . . . . . 163
THIS . . . . . . . . . . . . . . . 77, 153, 158
THIS, illegality for prefixed blocks 162
Time axis in CLASS SIMULATION . . 206
Time in CLASS SIMULATION . . . . . 206
Time, procedure in CLASS SIMULATION 207, 209
Timing clause in CLASS SIMULATION 211
TO . . . . . . . . . . . . . . . . 76
Trace of a model . . . . . . . . . 54
Transplantation . . . . . . . . . 168
Transput . . . . . . . . . . . . . 237
Transput, DEC 10 dependent parts, see part II 1000
Trigonometric functions . . . . . 289
TRUE . . . . . . . . . . . . . . . 77, 87, 146
TTY . . . . . . . . . . . . . . . 238, 245, 247, 254-256
TTY terminal . . . . . . . . . . . 256
TTY terminal, output to . . . . . 238
TTY WIDTH . . . . . . . . . . . . 254
Two way list . . . . . . . . . . . 195
Type . . . . . . . . . . . . . . . 83
Type ARRAY, as CLASS attribute . . 111
Type conversion (arithmetic) . . . 92
Type conversion(CHARACTER to INTEGER) 150
Type conversion(INTEGER to CHARACTER) 150
Type declaration . . . . . . . . . 89, 91
Type of arithmetic expression . . 140
Type of PROCEDURE parameters . . . 104
Types and constants . . . . . . . 83
Undefined values are impossible in SIMULA 115
Underscore (_) . . . . . . . . . . 73
Unformatted i/o, see part III . . 1000
UNIFORM random drawing procedure . 293
UNTIL . . . . . . . . . . . . . . 76, 175
updates, how to get info on . . . 2
Upper bound . . . . . . . . . . . 94
Upper case characters . . . . . . 68
Upper subscript bound . . . . . . 94
VALUE (Parameter transmission mode) 105
VALUE (Parameter transmission mode), default 104
Value assignment . . . . . . . . . 167
Value comparators . . . . . . . . 148
VALUE declaration of CLASS parameter 111
Value expression . . . . . . . . . 176
VALUE of a constant . . . . . . . 83
Value of controlled variable on exit 179
VALUE Parameter for procedure, table 104
VALUE parameter transmission, introduction 39
Value type . . . . . . . . . . . . 83, 91
VALUE, syntax . . . . . . . . . . 75
Values of variables, table of range 93
Variable . . . . . . . . . . . . . 132, 153
Variable length character strings (TEXTs) 231
Variable name declarations . . . . 91
Variable type declarations . . . . 91
Variable values, table of allowed values 93
Variable, assignment to . . . . . 132
Variable, use in expression . . . 131
Variable, value of . . . . . . . . 83, 132
VARYING declaration of character strings 231
Vector . . . . . . . . . . . . . . 94
Vertical stroke (|) . . . . . . . 66
VERTICAL TAB character . . . . . . 281
Video terminal, output to . . . . 247
VIRTUAL . . . . . . . . . . . . . 75
VIRTUAL attributes of files . . . 238-240, 244, 252
VIRTUAL quantities . . . . . . . . 119
VIRTUAL, attribute redefinition . 116
VIRTUAL, semantics . . . . . . . . 119
VIRTUAL, syntax . . . . . . . . . 112
WAIT in CLASS SIMULATION . . . . . 206-207, 209
WHEN . . . . . . . . . . . . . . . 76, 183
WHILE . . . . . . . . . . . . . . 76, 173
WHILE statement . . . . . . . . . 173
WHILE, ambiguity with . . . . . . 164
Whole number . . . . . . . . . . . 85, 87, 91
WIDTH of TTY . . . . . . . . . . . 254