Chapter 0
General Introduction

Introduction

SIMULA is a general purpose programming language. It inherits the algorithmic properties of ALGOL 60 and introduces methods for structuring data. The main characteristic of SIMULA is that it is easily modelled towards specialized problem areas, and hence can be used as a basis for Special Application Languages.

In this Standard the name SIMULA is considered synonymous with SIMULA 67. Although there exists a predecessor, SIMULA I, this latter language has achieved limited use. It is recommended that the language defined in this Standard be referred to as "Standard SIMULA".

SIMULA includes most of the ALGOL 60 language. Wherever ALGOL is used in this Standard it relates to the STANDARD ALGOL 60 definition (ISO 1538).

Scope and field of application

This Standard establishes the definition of the programming language SIMULA and specifies conformity rules to related products, such as programs and processors. Its purpose is to facilitate interchange and promote portability of SIMULA programs between data processing systems.

This Standard specifies:

  1. The syntax, semantics and representation of SIMULA,
  2. Characteristics of processors (see 4.2.1) and their accompanying documents, and of SIMULA programs, required for conformity to this Standard,
  3. What is left to the discretion of the implementor, or to be specified for each implementation.

This Standard does not specify:

  1. Results or issues that are explicitly left undefined or said to be undefined,
  2. How non-valid programs are to be rejected and how this will be reported,
  3. The relationship of the hypothetical computer, used to explain the actions which constitute the elaboration of a program, to an actual data processing system.

REFERENCES

ISO 646-1973: The 7-bit coded character set for information processing interchange.
ISO 1538-1984: Programming languages - ALGOL 60
ISO 2022-1982: ISO 7-bit and 8-bit coded character sets

"Common Base Language" by O.-J. Dahl, B. Myhrhaug and K. Nygaard Norwegian Computing Center 1984. (ISBN 82-539-0225-5)

DEFINITIONS

For the purpose of this Standard the following definitions apply.

Note:

Several terms used in this Standard are explained at the appropriate place in Part II (Description of the language). For convenience some of these have been included here too, at times with a simplified definition. It is understood, however, that no difference of meaning is considered to exist, and all definitions of a term are equivalent.

SIMULA Program

Potential program:

A text, that is a sequence of characters or typographical marks, meant to be a sequence of tokens constituting a SIMULA program.

Valid program:

A potential program that is a program according to the rules in this Standard.

Non-valid program:

A potential program that is not a program but can be turned into one by deleting or inserting a number of symbols.

Elaboration of a program:

A sequence of actions specified by the semantics to be carried out.

SIMULA program:

A valid program whose elaboration is defined by this Standard for an indicated class of input data.

SIMULA Processors

Processor:

A compiler, translator or interpreter, in combination with a data processing system, that accepts a potential program, transcribed in a form that can be processed by that data processing system, reports whether the potential program is valid or not, and if so requested is able to execute it, if it has not rejected it.

SIMULA Implementations

Implementation:

A well-documented processor is said to establish an implementation of the language SIMULA.

Implemented language:

The version of the language defined by the implementation.

Extension:

A rule in the implemented language that

  1. is not given in this Standard
  2. does not cause any ambiguity when added to this Standard (but may serve to remove a restriction)
  3. is within the scope of this Standard.

Implementation-defined:

What is to be specified for each implementation.

Implementation-dependent:

What is left to the discretion of the implementor.

CONFORMITY

Requirements

Conforming programs

Conformity to this Standard requires for a program that

  1. it shall be a SIMULA program
  2. a set of input data shall be given for which it has a defined meaning.

Conforming processors

Conformity to this Standard requires for a processor that

  1. it shall accept valid programs as being valid,
  2. it shall reject non-valid programs as being non-valid,
  3. it shall not elaborate a SIMULA program differently from what is defined in this Standard,
  4. it shall be accompanied by documents complying with the requirements below.

Documentation

It is required for the documents accompanying a conforming processor that these shall describe clearly

  1. its purpose, the name of the implemented language, if not SIMULA, and the environment (hardware and software) in which it will work,
  2. its intended properties, including
  3. all differences between the implemented language and the language defined in Part II of this Standard,
  4. its logical structure,
  5. the way to put it into use.

Conforming implementations

A conforming implementation shall comply with the above requirements for a processor and its accompanying documents.

Quantitative restrictions

The requirements specified in 4.1 shall allow for quantitative restrictions to rules stated or implied as having no such restriction in this Standard, but only if they are fully described in the documents with the implementation. These restrictions are to be considered implementation-defined in as far as they are not dependent of any momentary resource restraint during execution of a program.

Extensions

An implementation that allows for extensions in the implemented language is considered to conform to this Standard, notwithstanding 4.1 if

  1. it would be conforming when the extensions were omitted,
  2. those extensions are clearly described with the implementation,
  3. while accepting programs that are non-valid according to the rules given in Part II of this Standard, it provides means for indicating which part, or parts, of a program would have led to its rejection, had no extensions been allowed (cf. Part II, ch. 16),
  4. the implemented language is a super-language of SIMULA.

Extensions are allowed only if the following conditions are fulfilled:

  1. The implementor provides a translator program, which takes any program accepted by that implementation and translates it into a valid program. The resulting program may contain a minimum of calls to non-SIMULA procedures in cases where this is absolutely necessary due to a lack of facilities in the language.
  2. Each implementation has a switch which must be set to make the compiler accept programs with extensions.

An implementation which allows extensions, shall give warning messages for the use of such extensions.

Valid programs using extensions shall be described as "conforming to the SIMULA Standard but for the following indicated parts".

Subsets

This Standard does not include subsets.

TESTS

Whether an implementation is a conforming implementation may possibly be detected by a suite of test programs. If there is any uncertainty or doubt regarding acceptance of these programs then the conclusion drawn from the actual behavior of the processor will prevail over those derived from its accompanying documents.

APPENDICES

Appendices contained within this document are not part of this Standard.