SIMULA 67(ID:301/sim053)

Object-oriented simulation language 


for SImple Universal LAnguage

Generla purpose language derived from Algol and Simula 1, with influences from SIMSCRIPT

Introduced important OOP concepts like classes and objects, inheritance, and dynamic binding.  The language was defined in 1967 in the "SIMULA Common Base Language". The language definition has been maintained by the SIMULA Standards Group (SSG), and the latest definition is found in the "SIMULA Standard", adopted by the SSG in 1986.

The "object-orientation" involved in SIMULA 67 pertains to the "object-system" with comprised the system which the simulation stood for, and was an extension to the (then current) notion of "problem-oriented" languages as opposed to "machine-oriented" languages.

Simula 67 works as a general-purpose language because it models all programming problems as simulations - it is modelling real-world systems every time it runs. Thus it is properly an "object-system"-oriented language, which is a move away from the ideal of an abstract algorithm being the dominating force in program design. The notion of an "object" as an entity per-se does not arrive until the biological metaphor involved in the creation of SmallTalk.




People:
Structures:
Related languages
Simscript N => SIMULA 67   Incorporated some features of
SIMULA => SIMULA 67   Evolution of
SIMULA 67 => 2.PAK   Based on
SIMULA 67 => ABEL   Evolution of
SIMULA 67 => Astral   Extension of
SIMULA 67 => BETA   Evolution of
SIMULA 67 => C with Classes   Influence
SIMULA 67 => DELTA   Evolution of
SIMULA 67 => DEMOS   Extension of
SIMULA 67 => DISCO   Based on
SIMULA 67 => FLEX   Subset
SIMULA 67 => Framework Simula   Evolution of
SIMULA 67 => GPSSS   Augmentation of
SIMULA 67 => HEOPS   Incorporated features of
SIMULA 67 => LOGLAN   Evolution of
SIMULA 67 => MODEL   Incorporated some features of
SIMULA 67 => Newton   Incorporated some features of
SIMULA 67 => POOMAS   Subset

References:
  • Dahl, O.-J. "Discrete event simulation languages" (notes from NATO school lectures) pp 349-394 view details
          in Genuys, F. ed.: Programming Languages. Academic Press, London, 1968 view details
  • Dahl, O.-J. and Nygaard, K. "Class and subclass declarations" view details
          in Buxton, J. ed.: Simulation Programming Languages. Proceedings from the IFIP Working Conference in Oslo, May 1967, North Holland, 1968. view details
  • Dahl, O.J., Myhrhaug, B., Nygaard, K., SIMULA 67 - Common Base Language. Norwegian Computing Center Forskningveien 1B, Oslo 3, Norway (May 1968). view details
          in Buxton, J. ed.: Simulation Programming Languages. Proceedings from the IFIP Working Conference in Oslo, May 1967, North Holland, 1968. view details
  • Dahl, Ole-Johan; Myhrhaug, Bjørn; Nygaard, Kristen "Some features of the SIMULA 67 language" view details Abstract: SIMULA 67 is a general purpose programming language with a built-in simulation capability similar to, but stronger than that of SIMULA I. SIMULA 67 has been developed by the authors at the Norwegian Computing Center. Compilers for this language are now being implemented on a number of different computers. Other compilers are in the planning stage. A main characteristic of SIMULA 67 is that it is easily structured towards specialized problem areas, and hence will be used as a basis for special application languages. SIMULA 67 contains the general algorithmic language ALGOL 60 as a subset, except for some very minor revisions. The reason for choosing ALGOL 60 as starting point was that its basic structure lent itself for extension. It was felt that it would be impractical for the users to base SIMULA 67 on still another new algorithmic language, and ALGOL 60 has already a user basis, mainly in Europe and the Soviet.
          in Proceedings of the second conference on Applications of simulations, 1968, New York, New York, United States view details
  • Ichbiah, Jean D. "Extensibility in Simula 67" pp84-86 view details Abstract: Simula 67 is a general purpose language developed at the Norwegian Computing Center. It evolved from an earlier simultation language called Simula 1 [1] Dahl and Nygaard however, realized that the problems that had to be solved for the implementation of a simulation language, namely the handling of complex data structures and of quasi-parallelism, were general problems. The language Simula 67 [2,3] was therefore defined as a general purpose language with a mechanism for extensions. The simulation capabilities are thus not defined in the base language Simula 67 but are rather defined by extension. This shows clearly how the language Simula 67, hereafter called Simula, is related to the idea of extensibility.

          in [ACM] SIGPLAN Notices 6(12) December 1971 Proceedings of the international symposium on Extensible languages Grenoble, France 1971 view details
  • Vaucher, Jean G. "Simulation data structures using SIMULA 67" pp255-260 view details Abstract: This paper describes the approach to the teaching of simulation at the University of Montreal. The language used is the present standard of SIMULA, sometimes referred to as SIMULA 67; however, the modelling approach is inspired from GPSS. This combination of an old and a new language has proved very fruitful. Little has so far been published on the new standard for SIMULA and it is hoped that the examples in this paper may serve as a painless introduction to simulation programming in this language.

          in The 5th Winter Simulation Conference 8-10 December 1971 Waldorf-Astoria Hotel, New York, NY view details
  • Kay, I. M. "Digital Discrete Simulation Languages. Discussion and Inventory" view details Extract: Simula and Simula 67
    Simula. Simula, an extension of Algol developed at the Norwegian Computing Center by O.-J. Dahl and K. Nygaard, is process-oriented: A process (user) continues until it is prevented from execution. An operative process is considered "active"; a queued or suspended process is considered "passive." Simula contains recursiveness, list-processing capability, and allows complete user access to Algol. An advanced version, also called Simula, is a general-purpose scientific language containing simulation capability.

          in Kay Ira M. and John McLeod,(Eds.), Progress in Simulation. New York: Gordon and Breach 1972 view details
  • Birtwistle, G. M. "Simula - Its Features and Prospects" in "High Level Programming Languages - The Way Ahead" (National Computing Centre, 1973) view details
          in Kay Ira M. and John McLeod,(Eds.), Progress in Simulation. New York: Gordon and Breach 1972 view details
  • Birtwistle, G. M.; Dahl, O-J.; Myhrhaug, B. and Nygaard, K. "Simula begin", Studentlitteratur, Lund, Sweden, 1973. view details
          in Kay Ira M. and John McLeod,(Eds.), Progress in Simulation. New York: Gordon and Breach 1972 view details
  • Birtwistle, G. M.; Dahl, O-J.; Myhrhaug, B. and Nygaard, K. "Simula begin", Studentlitteratur, Lund, Sweden, 1973. view details
          in Kay Ira M. and John McLeod,(Eds.), Progress in Simulation. New York: Gordon and Breach 1972 view details
  • Ichbiah, J.D., Morse, S.P., "General concepts of the Simula 67 Programming Language" view details
          in Halpern, Mark I and Shaw Christopher J (eds) "Annual Review in Automatic Programming" (7) 1973 Pergamon Press, Oxford view details
  • Sammet, Jean E. "Roster of Programming Languages for 1973" p147 view details
          in ACM Computing Reviews 15(04) April 1974 view details
  • Palme, Jacob "Experience from the Standardization of the SIMULA Programming Language" pp405-409 view details
          in Software — Practice and Experience 6(03) July-September 1976 view details
  • The Higher Order Language Working Group (HOLWG) Working Paper on 23 exisitng programming languages view details
          in Software — Practice and Experience 6(03) July-September 1976 view details
  • Wichmann, B. A. "Ackermann's function: a study in the efficiency of calling procedures" BIT 16 (1976), pp103-110 view details Abstract: A six line recursive procedure is used to assess the efficiency of the procedure calling mechanism in ALGOL-like languages. The results from some 40 systems varying from ALGOL 68 and PL/I to System Implementation Languages for minicomputers are presented and compared. A hundred to one variation in performance occurs with this test, the major reasons for which are given.
    Extract: Introduction
    Introduction
    There are several areas where traditional high-level languages are notably less efficient than hand-coding. Two of these areas are accessing array elements and calling procedures. Although in the former case much research has been done to improve the efficiency (resulting in the ALCOR and FORTRAN H2 compilers), little work has been published on calling procedures. In many scientific computations procedures are not called very frequently but this is not true in non-numeric work. Since modularisation by means of procedures is one of the most powerful programming tools in structuring complex problems, an inefficient calling mechanism can be very detrimental. In recent years there has been an increased use of high-level languages as assembler replacements ? the so-called 'System Implementation Languages'. Such languages must achieve a high degree of object code efficiency if their use is to become more widespread. The purpose of this paper is to compare the procedure calling mechanism of traditional high-level languages with both system implementation languages and machine-code.
    Extract: Ackermann's function
    Ackermann's function
    In view of the paper by Sundblad [1], a reasonable test case for study seemed to be the evaluation of Ackermann's function. This function has the advantage of being very short and not requiring large integer values for typical cases, yet being complex enough to be a significant test. The figures given in Sundblad's paper also provided a basis for comparison before many values had been obtained.
    Following Sundblad, we calculate Ackermann (3,n) for increasing n, in accordance with the complete program listing below. Three figures are determined from the test, the average execution time per call, the number of instructions executed per call and the amount of stack space required for each call. Although the average time per call can be determined from running the program, the other two figures cannot be found so easily and indeed, in many cases the figures are not available.

    [1]Y. Sundblad, The Ackermann function. A theoretical, computational and formula manipulative study. BIT 11 (1971), 107119.


    Extract: Acknowledgements
    Acknowledgements
    This work has been inspired by the International Federation for Information Processing Working Group 2.4. The desire of the group to obtain information on the performance of system implementation languages has led to tests such as this. It would not have been possible to write this paper without the active help of the following persons in running the test: ? Mr. L. Ammeraal (Mini-ALGOL 68), Dr R. Backhouse (B5500), Dr J. G. P. Barnes (RTL/2), Dr D. A. Bell (PL516), Dr H. Boom (Cyber 73 ALGOL 68), Mr P. Klint (C-UNIX), Mr R. Conradi (MARY, CYBER 74, 1108, CDC3300), Mr W. Findlay (PASCAL 1906A & machine code), Mr W. B. Foulkes (PASCAL 370/158). Professor G. Goos (B6700), Mr. V. Hath-way (BCPL MOD 1), Mr M. Healey (PL/I OPT), Professor J. J. Horning (Sue 11), Mr B. Jones (ALGOL 60, Dclft 370/165), Dr M. MeKeag (PASCAL & ALGOL 60, 1906S), Mr Z. Mocsi (R10), Dr J. Palme (DEC10 SIMULA & machine code), Mr M.J. Parsons (PALGOL), Dr M. Richards (BCPL), Professor J. S. Rohl (Manchester 1900 ALGOL), Mr P. D. Stephens (IMP), Dr P. Wetherall (ALGOL 68-R), Professor N. Wirth (PASCAL), Professor D. B. Wortman (370/165 machine code) and Professor W. A. Wulf (Bliss 10, Bliss 11 & machine code).
    Extract: Results of tests (altered to include authors where known)



        


































































































































































































































































































































    Language
    Computer
    Time per call (ms)

    Instructions per call

    Words per call

    Characteristic (see below)

    Written by (if stated)

    ALGOL 60

    B6700

    41.2

    16

    13

    ND2VO

    Professor G. Goos

    ALGOL 60

    B5500 Mk XV.l.01

    135

    19.5

    7

    NL2VO

    Dr R. Backhouse

    ALGOL 60

    EMAS 4/75

    46.7

    21

    18

    ND2VO

     

    ALGOL 60

    1906A Manchester

    29.2

    33.5

    30

    ND2VR

    Professor J. S. Rohl

    ALGOL 60

    KDF9 Mk2

    532

    68.5

    10

    CD2VR

     

    ALGOL 60

    1906S XALV

    70.9

    (120)

    13

    CD2TR

    Dr M. McKeag

    ALGOL 60

    370/165 Delft

    43.8

    (142)

    ?

    CD2TR

    Mr B. Jones

    ALGOL 60

    NU 1108

    175

    (175)

    9

    CD2TR

    Mr R. Conradi

    ALGOL W

    360/67 Mk2

    121

    (74)

    (16-45)

    HD2TR

     

    IMP

    ICL 4/75

    46

    17.5

    18

    ND2VO

    Mr P. D. Stephens

    SIMULA

    1108

    120

    (120)

    9

    HD2TR

    Mr R. Conradi

    SIMULA

    DEC1O(KI1O)

    317

    (158)

    ?

    HD2TR

    Dr J. Palme

    SIMULA

    CYSEN 74

    380

    (800)

    (15)

    HD2TR

    Mr R. Conradi

    ALGOL 68

    1907F (no heap)

    134

    28

    15

    NO2VO

    Mr. L. Ammeraal

    ALGOL 68

    1907F (heap)

    167

    34

    15

    HD2VR

    Mr. L. Ammeraal

    ALGOL 68

    CDC 6400(subset)

    45.3

    51

    ?

    HD2VO

    Dr P. Wetherall

    ALGOL 68

    Cyber 73 vl.0.8

    67.8

    (60)

    7

    HD2VR

    Dr H. Boom

    Bliss 10

    DEClO(KAlO)

    53.15

    15

    5

    NLWVR

    Professor W. A. Wulf /Mr Z. Mocsi

    PL/I

    360/65 OPT v1.2.2

    101

    (61)

    68

    HD2AO

    Mr M. Healey

    PL/I

    360/65 F v5.4

    351

    (212)

    (70)

    HD2AR

     

    PASCAL

    1906S

    19.1

    32.5

    11

    HDWVR

    Professor N. Wirth/Mr W. Findlay/Dr M. McKeag

    PASCAL

    CDC 6400

    34

    38.5

    6

    HDWVO

    Professor N. Wirth

    PASCAL

    370/158

    39

    42.5

    30

    HDWVE

    Professor N. Wirth/Mr W. B. Foulkes

    RTL/2

    4/70

    46

    14.5

    14

    NLWVO

    Dr J. G. P. Barnes

    RTL/2

    PDP11/20

    (107)

    30.5

    ?

    CLWVH

    Dr J. G. P. Barnes

    PALGOL

    PDP11/20

    (46)

    13

    3

    NLWVO

    Mr M.J. Parsons

    Bliss/11

    PDP11/20 OPT

    31

    8

    2

    NLWVO

    Professor W. A. Wulf /Professor J. J. Horning

    MARY

    SM4

    105

    30.5

    9

    COWVR

    Mr R. Conradi

    CORAL 66

    MOD 1

    (21)

    15.5

    3

    NLWVO

     

    PL516

    DDP516

    84.5

    37

    2

    CLWVH

    Dr D. A. Bell

    C (UNIX)

    PDP 11/45

    50.4

    26

    ?

    NLWVR

    Mr P. Klint

    BCPL

    370/165

    5.9

    19

    9

    NLWVR

    Dr M. Richards

    BCPL

    PDP 11/45

    48

    20.5

    7

    NLWVO

    Dr M. Richards

    BCPL

    MOD 1

    (35)

    25

    7

    NLWVR

    Dr M. Richards/Mr. V. Hathaway

    Machine code

    Most machines

    ?

    5-14

    1-2

    NLWVO

    Dr J. Palme/Professor D. B. Wortman /Professor W. A. Wulf
    Extract: Program listing
    Program listing
    begin
    integer i, j, k, k1; real t1, t2;
    integer procedure Ackermann(m, n); value m, n; integer m, n; Ackermann := if m = 0 then n + l
    else if n = 0 then Ackermann(m -1,1) else Ackermann(m - 1, Ackermann(m, n - 1));
    k:= 16; k1 := 1; for i := 1 step 1 until 6 do begin
    t1 := cputime;
    j : = Ackermann(3, i);
    t2 := cputime;
    if j = A;-3 then
    outtext(1, 'WRONG VALUE'); outreal(1, t2 ? t1);
    comment Now output time per call;
    outreal(1, 3 x (t2 - t1)/(512 x k1 - 15 x k + 9x i + 37))); k1 := 4 x k1; k := 2 x k end end
    Extract: Properties of the algorithm
    Properties of the algorithm
    To determine the execution characteristics of the test one needs the following properties of the algorithm (which can be easily proved by induction). The number of executions of each leg of the algorithm in calculating Ackermann (3, n) is:
    first leg:          (64x4|n-    72x2|n + 6xn + 26)/3
    second leg:       (                     24 x 2 | n - 3 x n - 12)/3
    third leg:         (64x4|n-    72x2|n + 6xn + 23)/3
    total
    no. of calls =   (128 x4|n-   120x2|n + 9xn + 37)/3
    Hence for large n, the average number of instructions per call is half the number of instructions in the first and third legs. Both legs contain the procedure entry and exit overheads and the third leg includes two unsuccessful tests for equality with zero. So the number of instructions executed per call can be found by examining the machine code produced by the compiler. Unfortunately this is not always easy and sometimes almost impossible. To provide an approximate comparative value, an estimate has been made from the time using a Gibson mix value [2] to extrapolate from a similar machine. In a few cases, the instructions executed arc known but the time has not been measured. In these cases, an estimate for the time is given based upon published instruction times.
    The amount of stack space required by the program is determined by the maximum depth of procedure calls. This is given by Sundblad as
    Ackermann(3, n) - 1 = 2 | (n + 3) - 4
    and occurs when the third leg is being evaluated at all but the last of those levels. Hence the amount of stack space required doubles when n is increased by one. For a more detailed discussion on the storage requirements and the definition of the 'maximum depth of recursion' see [5]. To measure this space, Sundblad observed the maximum value of 11 for which Ackermann (3, n) could be calculated using 26K words of store (which he called the 'capability'). Although this measurement is easy to take, it only provides a rough estimate of the space needed per call. Examination of the machine code of the third leg of the algorithm gives the precise value. In fact, the number of words per call is the difference in the address of 4m in the inner call to the address of the parameter in the routine. It is not easy to calculate this value from the code, and so a post-mortem print may be the easiest way to find the value. Rather than give the capability, the number of words per call is listed with the results. If only the capability is known, bounds can be given for the number of words per call by assuming that between 3K and 10K words are needed out of the 26K store for the program and run-time system.
    Extract: Notes on the results and Factors influencing the execution speed
    Notes on the results
    Estimates of missing values are included in the table in brackets and have been calculated in the manner described above. The program listing in all cases has followed the coding given very closely. The only exceptions are 1) the machine code examples, 2) the PASCAL and SUE systems which have no conditional expressions, and 3) PL516 which follows the hardware of the machine in not supporting recursion (stacking is performed by subroutines).

    Factors influencing the execution speed
    Factors influencing the call of a recursive procedure vary from inherent problems with the architecture of the machine to purely software problems on the design of the procedure calling mechanism. Against each of the results above is a sequence of letters and digits which describes the principle characteristics governing the execution performance.
    Recursion. On most modern machines with a few base registers and indexing facilities, the basic overhead of recursion is very small indeed. A few minicomputers do not have adequate base registers or addressing facilities to support recursion. The Honeywell DDP5l6 is of this type, hence with the high-level assembler PL516 stacking must be performed explicitly. On some machines, although the addressing logic is available an additional time penalty occurs by addressing via pointers. On the Modular 1 implementation of CORAL 66, recursion is an option. In fact the code produced with recursion is more efficient than that without recursion. The reason for this is that the short address length of the Modular 1 means that base registers must be loaded to access the variables of another procedure. This is a larger overhead than that incurred using a single stack register which only needs to he incremented and decremented by a small amount. Without recursion, the number of instructions is increased to 19.5 (30% more).
    Storage allocation. In order to execute this program, a stack storage scheme is necessary. It is sometimes possible on conventional hardware to use an area in the store as stack without performing an explicit software check for stack overflow. One can then rely upon a hardware address violation which should permit the output of a suitable diagnostic. Such systems are marked by an N, whereas C denotes a software stack overflow check. Languages such as ALGOL 68, PL/I and SIMULA require more than a simple stack and hence must perform an overflow check in a manner which allows a recovery to perform some garbage collection. Systems like this arc marked with an H. PASCAL permits additional storage apart from the stack but without garbage collection. Although no garbage collection is involved, PASCAL is marked with an H. Only SIMULA requires an actual garbage collection during the execution of this test. The method used to administer the stack is partly a matter of language design and partly a matter of implementation. For instance, although ALGOL 68 requires a heap, the ALGOL 68-R implementation will run a stack only if the program does not require the heap. The difference, shown above, is that an additional subroutine is called on procedure entry to check that adequate stack space is available.
    Complete display. Block structured languages in general require a base pointer for every block whose variables can be accessed at the relevant part of the program. This facility is marked with a D. Languages such as BCPL and Burroughs B5500 ALGOL restrict access to local and global identifiers only, permitting a significant economy in pointers. These languages are marked with an L. The actual method of implementing the display can vary independently of the language. For instance, ALGOL W and IMP have every base pointer in a register, the PASCAL implementations above backchain the display (from the local procedure) and ALGOL 68-R keeps a copy in core of the full display in the local block. In almost all cases, there will be small variations in the calling overhead depending upon the relevant positions (in the display) of the call and the procedure.

    Dynamic stack storage. In ALGOL 60, the sizes of arrays are not, in general, known until program execution. This facility, implemented with second order working store, requires a small overhead on the administration of stack storage even when no arrays are being used, as in this test. Languages requiring such storage are marked with a 2 whereas systems allowing only storage whose size can be determined at compile time are marked with a W. PALGOL and RTL/2 are LW languages and hence require only one stack pointer (and one pointer for static storage depending upon the addressing structure).
    Parameter handling. The most expensive mechanism is marked with a T which denotes a 'thunk' that is required to implement the ALGOL 60 call by name [4]. A thunk can be avoided with this test by performing all parameter checking at compile time and using only the value mechanism (V). The KDF9, B5500 and Atlas ALGOL compilers all use the value mechanism. The use of the thunk mechanism by the other ALGOL 60 compilers is caused by the problem of handling the call of formal procedures whose parameters cannot be specified [3]. With value parameters, the ICL 1900 ALGOL compiler uses a simplified thunk mechanism but the Manchester ALGOL compiler uses the value mechanism. The PL/I systems use call by address which is marked with an A. With recursion, the addresses of parameters are dynamic and in consequence this method is less efficient than call by value.
    Open code or subroutines. Systems which handle this test entirely by open code are marked with an O, whereas the use of subroutines is marked with an R. The PL/I optimising compiler generates a subroutine call, but it is not invoked unless insufficient stack space is given (which did not happen in this
    case).
    Extract: Conclusion
    Conclusion.
    Ackermann's function provides a simple method of comparing the efficiency of the procedure calling mechanism of a language permitting recursion. The results show a very wide variation in performance even for languages containing no inherent complications. Additional instructions required in ALGOL 68, PL/I and PASCAL to check for stack overflow are quite insignificant compared to the hundreds of extra instructions executed by the inefficient implementations of ALGOL 60. There is no doubt that 'System Implementation Languages' give very much better results on this test without reducing the facilities to the programmer. Machine independence seems to be realised in this case without any measurable cost as BCPL shows.
    Does Ackermann s function represent a good test for a system implementation language? Unfortunately no statistical information is available to the author on the use of procedures in operating systems and compilers etc. Hence it is not known if, for instance, two parameters is typical. The large amount of stack space used is certainly not typical and can result in pathological situations. For instance, stack space is claimed in 64 word units under George 3 on a 1906A, but is not released. Hence during the first part of the algorithm when the stack is being increased a large operating system overhead occurs. During the second part when the stack is rarely increased beyond its previous maximum, there is no significant overhead. The computational part of testing for the equality with zero, jumping and adding or subtracting one seems very typical of non-numeric work. On the 360 computer, the fact that the the algorithm is very short ( <4K bytes) results in a small saving, but on the IMP compiler which can take advantage of this the speed was only the increased by 3%.

    From the better figures produced by system implementation languages, the code for Ackermann is roughly divided as follows:
    instructions
    subroutine entry and exit      2 stacking return address        1 setting up environment        3 checking for stack overflow     2 (if check made) restoring old environment      3 (on procedure exit) setting parameters          2x1=2
    body of Ackermann         8
    Total                   21

          in Software — Practice and Experience 6(03) July-September 1976 view details
  • Foster, J. M. and Foster, P. D. Abstract data and functors pp161-167 view details
          in Proceedings of the Strathclyde ALGOL 68 conference Glasgow, Scotland 1977 view details
  • Sammet, Jean E "Roster of programming languages for 1976-77" pp56-85 view details
          in SIGPLAN Notices 13(11) Nov 1978 view details
  • Eklundh, Berth "SIMULA-a way of thinking" view details Abstract: SIMULA as a tool for modelling and programming is reviewed. Some basic questions that arise in a simulation context are dealt with, and the evolution steps from a percepted reality to final simulation program are examined and exemplified. The modelling step is considered the most important and more effort is put in the analysis of this than in a semantic and syntactical definition. A specific example is given, and SIMULA is used to simulate that example. The importance of conceptually wellsuited building-blocks for simulationtasks is discussed, and the concepts of SIMULA are put in relation to program evaluation.

          in The 11th Winter Simulation Conference 3-5 December 1979 Holiday Inn Embarcadero, San Diego, CA view details
  • Atkins, S. M. "A comparison of SIMULA and GPSS for simulating sparse traffic" Simulation 34, 3 (March 1980), 93- 100. view details
          in The 11th Winter Simulation Conference 3-5 December 1979 Holiday Inn Embarcadero, San Diego, CA view details
  • Palme, Jacob "Uses of the SIMULA Process Concept" Foersvarets Forskningsanstalt, Stockholm (Sweden). Feb 81, FOA-C-10172-M6 view details
          in The 11th Winter Simulation Conference 3-5 December 1979 Holiday Inn Embarcadero, San Diego, CA view details
  • Steensgaard-Madsen, J. " Statement-Oriented Approach to Data Abstraction" pp1-10 view details Extract: Introduction
    1. INTRODUCTION

    Programming languages traditionally offered procedures and functions as the only means of abstraction, that is, of providing powerful and high-level concepts while suppressing the details of their realization. The last ten years have seen many efforts to devise better abstraction facilities. SIMULA 67, Concurrent PASCAL, MODULA, CLU, and MESA are some of the newer languages offering abstraction mechanisms.

    The facilities offered by those languages are intended to hide by abstraction the interplay of different operations on the same data and to prevent access to the common data except by use of the abstract operations. Most researchers have looked to the type concept as a basis for an abstraction mechanism. However, no single type-based approach has been generally accepted.

    The approach taken in this paper differs from previous ones in a fundamental way. It is not based on a generalization of the type concept. Instead, the emphasis is on statements and procedures.

    The syntax we introduce is similar to that used for other proposed abstraction mechanisms. In order to avoid confusion, the reader must initially assume a simplified notion of types. A type is considered to be a set of values. From a theoretical point of view a type is considered to be a set component of an algebra, and a distinction is made between an algebra and its sets of values. This attitude differs essentially from Guttag and Horning's [5]. The algebra itself can be identified with other parts of this proposal, but this is not done explicitly here.

    This paper introduces the proposed language constructs in steps, each including examples. Section 2 concentrates on how to use an abstraction; it is divided into subsections of increasing complexity. Section 3, showing how abstractions are defined, is also subdivided according to complexity. Section 4 specifies the semantics using rewriting rules and thus indicates a possible implementation. Section 5 presents some final remarks.
          in TOPLAS 3(1) January 1981 view details
  • Kreutzer, W. review of Palme 1982 in ACM Computing Reviews August 1982 view details Abstract: Tools should be well-engineered, versatile, efficient, and safe relative to a community of users and a range of purposes. To build a program we recursively encode and encapsulate "relevant facts" into REPRESENTATIONs, consisting of constellations of SYMBOLs (data, operations, relationships), and define finite and unambiguous INTERPRETATIONs, describing PROCESSes (control relationships).

    Any PROGRAM can therefore be conceptualized as a cluster of hierarchically organized layers of coexisting and cooperating OBJECTS with (multilevel) (NAME, STRUCTURE, BEHAVIOR) specifications mapped into levels of data representation, data transformation, and control primitives available in a particular language and programming environment.

    SIMULA67 [1] was the first software tool to support this object-oriented view of computations, and has been very influential in language design. Outside Europe it unfortunately never achieved the widespread use and recognition it deserves, probably because of its lack of support by any major computer manufacturer. SIMULA may be mainly known as a discrete event simulation language [2]. It is, however, also an extremely flexible and powerful general purpose tool for application and systems program development.

    In this article, J. Palme, the developer of the widely popular DEC10 SIMULA implementation, "illustrates by some examples for existing programs how the process aspect of the CLASS concept can be used to structure programs in neat ways. All the examples are taken from real production programs in heavy usage today, but the examples have been simplified in this paper to illustrate the main ideas."

    In line with the author's intention the first brief section serves as an introduction for readers not familiar with the SIMULA67 programming language. It introduces the concepts of CLASSes, class hierarchies, and COROUTINE sequencing. The four following chapters illustrate SIMULA's usefulness for systems programming tasks. Palme discusses program fragments for converting a sequential file of records into three separate data streams for the purpose of printing mailing labels (coroutines), the interactive evaluation of Boolean expressions used to retrieve data records (encoding interpreters for operators in a hierarchy of classes), the simulative testing and debugging of programs used to transfer messages between computerized conferencing systems at different computer sites through a computer network (class instances operating concurrently and exchanging data via a message buffer), and the design and implementation of menu-structured user interfaces (class hierarchies).

    The examples nicely illustrate SIMULA's conceptual power as a data and process abstraction tool for objectoriented programming styles. Some more information, especially for examples 4 and 5, would, however, be helpful to the reader, especially if he is not overly familiar with the SIMULA language. Unfortunately, only few references on the SIMULA language itself are given, even though there is now a small set of good introductory textbooks and over-view articles [2, 3, 4]. The historical development of the concepts reported in the article is traced in [5].

    There are two minor typesetting errors in the program given in Section 3. The "loop;" in line 4 should be a "loop:"; and the "found;" should be a "found: I" in line 19.

    In summary, this paper gives another interesting demonstration of SIMULA's capability to represent complex programming problems dealing with layered environments and multiple interacting data and control streams in a natural way. It is regrettable that this conceptual power has not yet been more widely recognized and utilized.

    REFERENCES
    [1] DAHL, O. J.; MYHRHAUG, B.; AND NYGAARD, K. SIMULA67 common base language, NCC Publication S-52, Norwegian Computing Centre, Oslo, 1972.
    [2] FRANTA, W. R. The process view of simulation. Elsevier NorthHolland, New York, 1977.
    [3] BIRTWISTLE, G. M.; DAHL, O. J.; MYHRHAUG, B.; AND NYGAARD, K. SIMULA begin (2nd e`), Auerbach, New York, 1979.
    [4] BROWN, W. A. SIMULA for those who know FORTRAN, PL/I, or BASIC, NCC Publication S-656, Norwegian Computing Centre, Os10, 1979.
    [5] DAHL, O. J.; AND NYGAARD, K. The development of the SIMULA language, in History of programming languages, R. L. Wexelblat (Ed.), Academic Press, Inc., New York, 1981.

          in TOPLAS 3(1) January 1981 view details
  • Papazoglou, M P.; Georgiadis, P I.; Maritsas, D G. "An outline of the programming language SIMULA" pp107 - 131 view details
          in Computer Languages 9(2) view details
  • "Data Processing Programming Languages SIMULA", Swedish Standard SS 63 61 14 (1987), ISBN 91-7162-234-9, available through ANSI. view details
          in Computer Languages 9(2) view details
  • "Et portabelt Simula-system bygget paa C." Hovedoppgave til cand.scient-graden av Sverre Johansen. Institutt for informatikk, Universitetet i Oslo, Mai 1987. view details
          in Computer Languages 9(2) view details
  • "Object-Oriented Programming with SIMULA", Bjorn Kirkerud, A-W 1989. view details Abstract: The class concept of the SIMULA programming language is well known as the father of the concept of abstract data types. A SIMULA class can however also act as a process. The paper illustrates by some examples from existing programs how the process aspect of the class concept can be used to structure programs in neat ways. All the examples are taken from real production programs in heavy usage today, but the examples have been simplified in this paper to illustrate the main ideas.
          in Computer Languages 9(2) view details
  • "Viderefoering og testing av et portabelt Simula-system." Hovedoppgave til cand.scient.-graden av Terje Mjoes. Institutt for informatikk, Universitetet i Oslo, April 1989. view details
          in Computer Languages 9(2) view details
  • J. R. Holmevik, "Compiling SIMULA: a historical study of technological genesis" pp25-37 view details
          in Annals of the History of Computing 16(1) Spring 1994 view details
  • George Gray "UNIVAC and ALGOL" Unisys History Newsletter 6(2) June 2002 view details Extract: Information
    MAD was developed at the University of Michigan in 195960 for the IBM 704. It was very widely used on the IBM 7090 and 7094, the Philco 2000, and UNIVAC 1100 computers during the 1960s for the purpose of teaching programming to college students. Michigan published a reference manual, but most students learned MAD from the MAD PRIMER, written by Elliott Organick of the University of Houston and distributed by Ulrichs Book Store of Ann Arbor, Michigan. Organick also wrote a more widely used FORTRAN PRIMER. The MAD compiler for the UNIVAC 1100 computers called RALPH was developed at the University of Maryland. The name RALPH is an acronym of sorts: Reentrant Algorithmic Language Processor with H just for the H of it. (The explanation of the acronym is supplied by George Baltz, formerly at the University of Maryland.) The RALPH processor could compile either FORTRAN or MAD, depending on the option selected.
    MAD is perhaps most famous for the line printer picture of Alfred E. Neumann which was printed when an attempted compilation had too many errors. Underneath the picture it printed the caption: See this man about your program--He might want to publish it. He never worries--but from the looks of your program, you should. MAD faded from the scene in the 1970s.

    A very simple MAD program follows:

                                                                        
                INTEGER A                                                          
    START      A = 1                                                              
                WHENEVER A .G. 0                                                    
                PRINT COMMENT $ A GTR 0$                                            
                OTHERWISE                                                          
                PRINT COMMENT $A LEQ 0$                                            
                END OF CONDITIONAL                                                  
                PRINT COMMENT $ END $                                              
                END OF PROGRAM

    The WHENEVER OTHERWISE END OF CONDITIONAL is equivalent to an if-else statement External link: Online copy at UNISIS History
          in Annals of the History of Computing 16(1) Spring 1994 view details
    Resources
    • Simula to C translator

      "

    • bnf:


      &nbsp;EBNF - Syntax of SIMULA
      67



      &nbsp; 1&nbsp;&lt;program&gt; ::
      {&lt;block prefix&gt;}&lt;block&gt; | {&lt;block prefix&gt;}&lt;compound
      statement&gt;
      &nbsp; 2&nbsp;&nbsp;&lt;block prefix&gt; ::= &lt;class
      identifier&gt;{(&lt;actual paremeter list&gt;)}
      &nbsp;
      3&nbsp;&nbsp;&nbsp;&lt;block&gt; ::= &lt;block head&gt;;&lt;compound
      tail&gt;
      &nbsp; 4&nbsp;&nbsp;&nbsp;&nbsp;&lt;block head&gt; ::= &lt;block
      head&gt;;&lt;declaration&gt; | BEGIN &lt;declaration&gt;


      &nbsp; 5&nbsp;&lt;declaration&gt; ::=
      &lt;type declaration&gt; | &lt;array declaration&gt; | &lt;switch
      declaration&gt; | &lt;procedure declaration&gt; | &lt;class declaration&gt; |
      &lt;external declaration&gt;
      &nbsp; 6&nbsp;&nbsp;&lt;type declaration&gt; ::=
      &lt;type&gt;&lt;identifier list&gt;
      &nbsp; 7&nbsp;&nbsp;&nbsp;&lt;type&gt;
      ::= BOOLEAN | CHARACTER | INTEGER | REAL | REF(&lt;class declaration&gt;) |
      TEXT
      &nbsp; 8&nbsp;&nbsp;&nbsp;&lt;identifier list&gt; ::= {&lt;identifier
      list&gt;,}&lt;identifier&gt;
      &nbsp; 9&nbsp;&nbsp;&lt;array declaration&gt;
      ::= {&lt;type&gt;} ARRAY &lt;array
      list&gt;
      &nbsp;10&nbsp;&nbsp;&nbsp;&lt;array list&gt; ::={&lt;array
      list&gt;,} &lt;array segment&gt;
      &nbsp;11&nbsp;&nbsp;&nbsp;&nbsp;&lt;array
      segment&gt; ::= &lt;identifier list&gt;[&lt;bound pair
      list&gt;]
      &nbsp;12&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;bound pair list&gt; ::=
      {&lt;bound pair list&gt;,}&lt;arithmetic expression&gt;:&lt;arithmetic
      expression&gt;
      &nbsp;13&nbsp;&nbsp;&lt;switch declaration&gt; ::= SWITCH
      &lt;switch identifier&gt; := &lt;switch
      list&gt;
      &nbsp;14&nbsp;&nbsp;&nbsp;&lt;switch identifier&gt; ::=
      &lt;identifier&gt;
      &nbsp;15&nbsp;&nbsp;&nbsp;&lt;switch list&gt; ::=
      {&lt;switch list&gt;,}&lt;designational
      expression&gt;
      &nbsp;16&nbsp;&nbsp;&lt;procedure declaration&gt; ::=
      {&lt;type&gt;} PROCEDURE &lt;procedure heading&gt;;&lt;proceduere
      body&gt;
      &nbsp;17&nbsp;&nbsp;&nbsp;&lt;procedure heading&gt; ::=
      &lt;procedure identifier&gt;{&lt;formal parameter part&gt;;{&lt;mode
      part&gt;;}&lt;specification
      part&gt;}
      &nbsp;18&nbsp;&nbsp;&nbsp;&nbsp;&lt;formal parameter part&gt; ::=
      (&lt;identifier list&gt;)
      &nbsp;19&nbsp;&nbsp;&nbsp;&nbsp;&lt;mode part&gt;
      ::= {&lt;value part&gt;;}&lt;name part&gt; | {&lt;name part&gt;;}&lt;value
      part&gt;
      &nbsp;20&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;value part&gt; ::= VALUE
      &lt;identifier list&gt;
      &nbsp;21&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;name
      part&gt; ::= NAME &lt;identifier
      list&gt;
      &nbsp;22&nbsp;&nbsp;&nbsp;&nbsp;&lt;specification part&gt; ::=
      {&lt;specification part&gt;;}&lt;specifier&gt;&lt;identifier
      list&gt;
      &nbsp;23&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;specifier&gt; ::=
      {&lt;type&gt;} ARRAY | LABEL | {&lt;virtual part&gt;;}&lt;identifier
      list&gt;
      &nbsp;24&nbsp;&nbsp;&nbsp;&lt;procedure body&gt; ::=
      &lt;statement&gt;
      &nbsp;25&nbsp;&nbsp;&lt;class declaration&gt; ::
      {&lt;prefix&gt;} CLASS &lt;class heding&gt;;{&lt;virtual part&gt;;}&lt;class
      body&gt;
      &nbsp;26&nbsp;&nbsp;&nbsp;&lt;prefix&gt; ::= &lt;class
      identifier&gt;
      &nbsp;27&nbsp;&nbsp;&nbsp;&lt;class heading&gt; ::= &lt;class
      identifier&gt;{&lt;formal paremeter part&gt;;{&lt;value
      part&gt;;}&lt;specification
      part&gt;}
      &nbsp;28&nbsp;&nbsp;&nbsp;&nbsp;&lt;class identifier&gt; ::=
      &lt;identifier&gt;
      &nbsp;29&nbsp;&nbsp;&nbsp;&lt;virtual part&gt; ::=
      VIRTUAL: &lt;virtual specification
      part&gt;
      &nbsp;30&nbsp;&nbsp;&nbsp;&nbsp;&lt;virtual specification part&gt;
      ::= {&lt;virtual specification part&gt;;}&lt;virtual specifier&gt;&lt;identifier
      list&gt;
      &nbsp;31&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;virtual specifier&gt; ::=
      LABEL | {&lt;type&gt;} PROCEDURE | SWITCH
      &nbsp;32&nbsp;&nbsp;&nbsp;&lt;class
      body&gt; ::= &lt;split body&gt; |
      &lt;statement&gt;
      &nbsp;33&nbsp;&nbsp;&nbsp;&nbsp;&lt;split body&gt; ::
      &lt;initial part&gt; INNER; &lt;compound
      tail&gt;
      &nbsp;34&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;initial part&gt; ::= BEGIN
      | &lt;block head&gt;; | &lt;initial
      part&gt;&lt;statement&gt;
      &nbsp;35&nbsp;&nbsp;&lt;external declaration&gt;
      ::= EXTERNAL {&lt;type&gt;} PROCEDURE &lt;external list&gt; | EXTERNAL CLASS
      &lt;external list&gt;
      &nbsp;36&nbsp;&nbsp;&nbsp;&lt;external list&gt; ::=
      {&lt;external list&gt;,}&lt;external
      item&gt;
      &nbsp;37&nbsp;&nbsp;&nbsp;&nbsp;&lt;external item&gt; ::=
      &lt;external identifier&gt; | &lt;identifier&gt; = &lt;external
      identifier&gt;


      &nbsp;38&nbsp;&lt;compound statement&gt; ::=
      BEGIN &lt;compound tail&gt;
      &nbsp;39&nbsp;&nbsp;&lt;compound tail&gt; ::= END
      | &lt;statement&gt;;&lt;compound
      tail&gt;
      &nbsp;40&nbsp;&nbsp;&nbsp;&lt;statement&gt; ::= &lt;label
      list&gt;&lt;statement&gt; | &lt;conditional statement&gt; | &lt;connection
      statement&gt; | &lt;repetition statement&gt; | &lt;unconditional
      statement&gt;
      &nbsp;41&nbsp;&nbsp;&nbsp;&nbsp;&lt;label list&gt; ::=
      {&lt;label
      list&gt;}&lt;label&gt;:
      &nbsp;42&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;label&gt;
      ::= &lt;identifier&gt;
      &nbsp;43&nbsp;&nbsp;&nbsp;&nbsp;&lt;conditional
      statement&gt; ::= &lt;if clause&gt;&lt;connection statement&gt; | &lt;if
      clause&gt;&lt;repetition statement&gt; | &lt;if clause&gt;&lt;unconditional
      statement&gt;{ELSE
      &lt;statement&gt;}
      &nbsp;44&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;if clause&gt;
      ::= IF &lt;Boolean expression&gt;
      THEN
      &nbsp;45&nbsp;&nbsp;&nbsp;&nbsp;&lt;connection statement&gt; ::= INSPECT
      &lt;object expression&gt;&lt;connection part&gt;{OTHERWISE
      &lt;statement&gt;}
      &nbsp;46&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;connection
      part&gt; ::= DO &lt;statement&gt; | &lt;selective
      part&gt;
      &nbsp;47&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;selective part&gt;
      ::= {&lt;selective part&gt;} WHEN &lt;class identifier&gt; DO
      &lt;statement&gt;
      &nbsp;48&nbsp;&nbsp;&nbsp;&nbsp;&lt;repetition
      statement&gt; ::=&lt;for statement&gt; | &lt;while
      statement&gt;
      &nbsp;49&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;for statement&gt; ::=
      FOR &lt;variable&gt; :- &lt;reference list&gt; DO &lt;statement&gt; | FOR
      &lt;variable&gt; := &lt;value list&gt; DO
      &lt;statement&gt;
      &nbsp;50&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;reference
      list&gt; ::= {&lt;reference list&gt;,}&lt;reference expression&gt; {WHILE
      &lt;Boolean
      expression&gt;}
      &nbsp;51&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;value
      list&gt; ::= {&lt;value list&gt;,}&lt;value list
      element&gt;
      &nbsp;52&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;value list
      element&gt; ::= &lt;value expression&gt;{WHILE &lt;Boolean expression&gt;} |
      &lt;arithmetic expression&gt; STEP &lt;arithmetic expression&gt; UNTIL
      &lt;arithmetic expression&gt;
      &nbsp;53&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;while
      statement&gt; ::= WHILE &lt;Boolean expression&gt; DO
      &lt;statement&gt;
      &nbsp;54&nbsp;&nbsp;&nbsp;&nbsp;&lt;unconditional
      statement&gt; ::= &lt;basic statement&gt; | {&lt;block prefix&gt;}&lt;block&gt;
      | {&lt;block prefix&gt;}&lt;compound
      statement&gt;
      &nbsp;55&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;basic statement&gt;
      ::= &lt;activation statement&gt; | &lt;assignment statement&gt; | &lt;dummy
      statement&gt; | &lt;goto statement&gt; | &lt;object generator&gt; |
      &lt;procedure
      satement&gt;
      &nbsp;56&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;activation
      statement&gt; ::=&lt;activator&gt;&lt;object expression&gt;{&lt;scheduling
      part&gt;}
      &nbsp;57&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;activator&gt;
      ::= ACTIVATE |
      REACTIVATE
      &nbsp;58&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;scheduling
      part&gt; ::= AT &lt;arithmetic expression&gt;{PRIOR} | DELAY &lt;arithmetic
      expression&gt; {PRIOR} | BEFORE &lt;object expression&gt; | AFTER &lt;object
      expression&gt;
      &nbsp;59&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;assignment
      statement&gt; ::= &lt;reference assignment&gt; | &lt;value
      assignment&gt;
      &nbsp;60&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;reference
      assignment&gt; ::= &lt;reference left part&gt; :- &lt;reference right
      part&gt;
      &nbsp;61&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;reference
      left part&gt; ::= &lt;variable&gt; | &lt;procedure
      identifiere&gt;
      &nbsp;62&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;reference
      right part&gt; ::= &lt;reference expression&gt; | &lt;reference
      assignment&gt;
      &nbsp;63&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;value
      assignment&gt; ::= &lt;value left part&gt; := &lt;value right
      part&gt;
      &nbsp;64&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;value
      left part&gt; ::= &lt;variable&gt; | &lt;procedure identifier&gt; | &lt;simple
      text
      expression&gt;
      &nbsp;65&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;value
      right part&gt; ::= &lt;value expression&gt; | &lt;value
      assignment&gt;
      &nbsp;66&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;dummy
      statement&gt; ::=
      &lt;empty&gt;
      &nbsp;67&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;goto
      statement&gt; ::= GOTO &lt;designational
      expression&gt;
      &nbsp;68&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;object
      generator&gt; ::= NEW &lt;class identifier&gt; {(&lt;actual parameter
      list&gt;)}
      &nbsp;69&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;procedure
      statement&gt; ::= {&lt;simple reference expression&gt;,}&lt;procedure
      identifier&gt;{(&lt;actual parameter
      list&gt;)}
      &nbsp;70&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;simple
      reference expression&gt; ::= &lt;simple object expression&gt; | &lt;simple text
      expression&gt;
      &nbsp;71&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;actual
      parameter list&gt; ::= {&lt;actual parameter list&gt;,}&lt;actual
      parameter&gt;
      &nbsp;72&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;actual
      parameter&gt; ::= &lt;expression&gt; | &lt;array identifier&gt; | &lt;procedure
      identifier&gt; | &lt;switch
      identifier&gt;
      &nbsp;73&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;array
      identifier&gt; ::= {&lt;simple object
      expression&gt;.}&lt;identifier&gt;
      &nbsp;74&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;procedure
      identifier&gt; ::= {&lt;simple reference
      expression&gt;.}&lt;identifier&gt;


      &nbsp;75&nbsp;&lt;expression&gt; ::=
      &lt;designational expression&gt; | &lt;reference expression&gt; | &lt;value
      expression&gt;
      &nbsp;76&nbsp;&nbsp;&lt;designational expression&gt; ::=
      &lt;simple designational expression&gt; | &lt;if clause&gt; &lt;simple
      designational expression&gt; ELSE &lt;designational
      expression&gt;
      &nbsp;77&nbsp;&nbsp;&nbsp;&lt;simple designational
      expression&gt; ::= (&lt;designational expression&gt;) | &lt;labal&gt; |
      &lt;switch designator&gt;
      &nbsp;78&nbsp;&nbsp;&nbsp;&nbsp;&lt;switch
      designator&gt; ::= &lt;switch identifier&gt;[&lt;arithmetic
      expression&gt;]
      &nbsp;79&nbsp;&nbsp;&lt;reference expression&gt; ::=
      &lt;object expression&gt; | &lt;text
      expression&gt;
      &nbsp;80&nbsp;&nbsp;&nbsp;&lt;object expression&gt; ::=
      &lt;simple object expression&gt; | &lt;if clause&gt;&lt;simple object
      expression&gt; ELSE &lt;object
      expression&gt;
      &nbsp;81&nbsp;&nbsp;&nbsp;&nbsp;&lt;simple object
      expression&gt; ::= (&lt;object expression&gt;) | NONE | &lt;function
      designator&gt; | &lt;local object&gt; | &lt;object generator&gt; | &lt;qualified
      object&gt; |
      &lt;variable&gt;
      &nbsp;82&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;fuction
      designator&gt; ::= &lt;procedure identifier&gt; {(&lt;actual parameter
      list&gt;)}
      &nbsp;83&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;local object&gt; ::=
      THIS &lt;class
      identifier&gt;
      &nbsp;84&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;qualified object&gt;
      ::= &lt;simple object expression&gt; QUA &lt;class
      identifier&gt;
      &nbsp;85&nbsp;&nbsp;&nbsp;&lt;text expression&gt; ::=
      &lt;simple text expression&gt; | &lt;if clause&gt;&lt;simple text expression&gt;
      ELSE &lt;text expression&gt;
      &nbsp;86&nbsp;&nbsp;&nbsp;&nbsp;&lt;simple text
      expression&gt; ::= (&lt;text expression&gt;) | NOTEXT | &lt;function
      designator&gt; | &lt;variable&gt;
      &nbsp;87&nbsp;&nbsp;&nbsp;&lt;value
      expression&gt; ::= &lt;arithmetic expression&gt; | &lt;Boolean expression&gt; |
      &lt;character expression&gt; | &lt;text value
      expression&gt;
      &nbsp;88&nbsp;&nbsp;&nbsp;&nbsp;&lt;simple arithmetic
      expression&gt; ::= &lt;simple arithmetic expression&gt; | &lt;if
      clause&gt;&lt;simple arithmetic expression&gt; ELSE &lt;arithmetic
      expression&gt;
      &nbsp;89&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;simple arithmetic
      expression&gt; ::= {{&lt;simple arithmetic expression&gt;}&lt;adding
      operator&gt;}&lt;arithmetic
      term&gt;
      &nbsp;90&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;adding operator&gt;
      ::= + | -
      &nbsp;91&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;arithmetic term&gt;
      ::= {&lt;arithmetic term&gt;&lt;multiplying operator&gt;}&lt;arithmetic
      factor&gt;
      &nbsp;92&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;multiplying
      operator&gt; ::= x | / |
      ÷
      &nbsp;93&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;arithmetic factor&gt;
      ::= {&lt;arithmetic factor&gt;^}&lt;arithmetic
      primary&gt;
      &nbsp;94&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;arithmetic
      primary&gt; ::= (&lt;arithmetic expression&gt;) | &lt;function designator&gt; |
      &lt;unsigned number&gt; |
      &lt;variable&gt;
      &nbsp;95&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;unsigned
      number&gt; ::= &lt;decimal number&gt; {&lt;exponent part&gt;} | &lt;exponent
      part&gt;
      &nbsp;96&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;decimal
      number&gt; ::= &lt;unsigned integer&gt;{&lt;decimal fraction&gt;} | &lt;decimal
      fraction&gt;
      &nbsp;97&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;unsigned
      integer&gt; ::= {&lt;unsigned
      integer&gt;}&lt;digit&gt;
      &nbsp;98&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;decimal
      fraction&gt; ::= .&lt;unsigned
      integer&gt;
      &nbsp;99&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;exponent
      part&gt; ::= \10{&lt;adding operator&gt;}&lt;unsigned
      integer&gt;
      100&nbsp;&nbsp;&nbsp;&nbsp;&lt;Boolean expression&gt; ::=
      &lt;simple Boolean&gt; | &lt;if clause&gt;&lt;simple Boolean&gt; ELSE
      &lt;Boolean expression&gt;
      101&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;simple
      Boolean&gt; ::= {&lt;simple Boolean&gt; \equ}
      &lt;implication&gt;
      102&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;implication&gt;
      ::= {&lt;implication&gt; \imp}&lt;Boolean
      term&gt;
      103&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;Boolean term&gt;
      ::= {&lt;Boolean term&gt; \or}&lt;Boolean
      factor&gt;
      104&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;Boolean
      factor&gt; ::= {&lt;Boolean factor&gt; \and}{\not}&lt;Boolean
      primary&gt;
      105&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;Boolean
      primary&gt; ::= (&lt;Boolean expression&gt;} | &lt;logical value&gt; |
      &lt;function designator&gt; | &lt;relation&gt; |
      &lt;variable&gt;
      106&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;logical
      value&gt; ::= TRUE |
      FALSE
      107&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;relation&gt;
      ::= &lt;qualification relation&gt; | &lt;reference relation&gt; | &lt;value
      expression&gt;
      108&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;qualification
      relation&gt; ::= &lt;simple object expression&gt;&lt;qualification
      tester&gt;&lt;class
      identifier&gt;
      109&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;qualification
      tester&gt; ::= IS |
      IN
      110&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;reference
      releation&gt; ::= &lt;object reference relation&gt; | &lt;text reference
      relation&gt;
      111&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;object
      reference relation&gt; ::= &lt;simple object expression&gt; &lt;reference
      comparator&gt;&lt;simple object
      expression&gt;
      112&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;reference
      comparator&gt; ::= == |
      =/=
      113&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;text
      reference relation&gt; ::= &lt;simple text expression&gt;&lt;refernce
      comparator&gt;&lt;simple text
      expression&gt;
      114&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;value
      relation&gt; ::= &lt;arithmetic relation&gt; | &lt;character relation&gt; |
      &lt;text value
      relation&gt;
      115&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;arithmetic
      relation&gt; ::= &lt;simple arithmetic expression&gt;&lt;relational
      operator&gt;&lt;simple arithmetic
      expression&gt;
      116&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;relational
      operator&gt; ::= &lt; | ¾ | = | „ | &gt; |

      117&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;chracter
      relation&gt; ::= &lt;simple character expression&gt;&lt;relational
      operator&gt;&lt;simple character
      expression&gt;
      118&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;text
      value relation&gt; ::= &lt;simple text value&gt;&lt;relational
      operator&gt;&lt;simple text
      value&gt;
      119&nbsp;&nbsp;&nbsp;&nbsp;&lt;character expression&gt; ::=
      &lt;simple character expression&gt; | &lt;if clause&gt;&lt;simple character
      expression&gt; ELSE &lt;character
      expression&gt;
      120&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;simple character
      expression&gt; ::= (&lt;character expression&gt; | &lt;character constant&gt; |
      &lt;function designator&gt; |
      &lt;variable&gt;
      121&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;character constant&gt;
      ::= '&lt;any basic symbol&gt;'
      122&nbsp;&nbsp;&nbsp;&lt;text value
      expression&gt; ::= &lt;simple text value&gt; | &lt;if clause&gt;&lt;simple text
      value&gt; 'ELSE' &lt;text value
      expression&gt;
      123&nbsp;&nbsp;&nbsp;&nbsp;&lt;simle text value&gt; ::=
      &lt;simple text expression&gt; | &lt;text
      constant&gt;
      124&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;text constant&gt; ::=
      '&lt;any sequence of basic symbols&gt;'


      125&nbsp;&lt;variable&gt; ::= &lt;simple
      object expression&gt;.&lt;variable&gt; | &lt;simple variable&gt; |
      &lt;subscripted variable&gt;
      126&nbsp;&nbsp;&lt;simple variable&gt; ::=
      &lt;identifier&gt;
      127&nbsp;&nbsp;&nbsp;&lt;identifier ::=
      {&lt;identifier&gt;}&lt;letter&gt; |
      &lt;identifier&gt;&lt;digit&gt;
      128&nbsp;&nbsp;&nbsp;&nbsp;&lt;letter&gt; ::=
      A|B|C|D|E|F|G|H|I|J|K|L|M|N|O|P|Q|R|S|T|U|V|W|X|Y|Z
      129&nbsp;&nbsp;&nbsp;&nbsp;&lt;digit&gt;
      ::= 0|1|2|3|4|5|6|7|8|9|0
      130&nbsp;&nbsp;&lt;subscripted variable&gt; ::=
      &lt;array identifier&gt;[&lt;subscript
      list&gt;]
      131&nbsp;&nbsp;&nbsp;&lt;subscript list&gt; ::= {&lt;subscript
      list&gt;,}&lt;arithmetic expression&gt;


      &nbsp;



      # special signs:


      ÷&nbsp;&nbsp;&nbsp; ... division - a line
      between two dots aligned verticaly&nbsp; (92)
      ^&nbsp;&nbsp;&nbsp; ... power -
      an up-arrow&nbsp; (93)
      \10&nbsp; ... power of ten - a lowered "10"&nbsp;
      (99)
      \equ ... logical equation - three strokes aligned verticaly&nbsp;
      (101)
      \imp ... logical implication - a "U" turned counter-clockwise&nbsp;
      (102)
      \or&nbsp; ... logical or - a sign like a "v"&nbsp; (103)
      \and ...
      logical and - like a flipped "v"&nbsp; (104)
      \not ... logical not "¬" - like
      a flipped and conter-clockwise turned "L" (104)


      &nbsp;


      &nbsp;


      &nbsp;

    • Ole-Johan and Kristen: some personal reminiscences
      "We oldies remember the good old days of the 1960's and 70's when hardly anyone gave a damn about objects. As a last aside, in 1960 I worked for one of the UK's grand old men of simulation, Tocher, for the summer. When I next saw him in 1974 I told him where I had been and he responded "Nygaard and Dahl. What's happened to them? They blazed onto the scene like comets in the early sixties, and then just vanished." Not quite, fortunately. I then tried to congratulate Tocher on using objects in the 1950's to structure his models (this he did calling them activity cycles. Tocher coded in octal not even assembler and resorted to an activity based simulation control structure). At this he blew his top and offendedly pronounced objects complete and utter rubbish."external link