                         IMP Core Environment Standard

                            Section 1: Introduction

       This document defines an environment for IMP programs in terms of
    available predefined procedures and their effects.  The existence of
    this document along with a commitment to conform to it as a standard has
    two major effects:

    1.      Implementors of new IMP systems can work from a formal
            definition in order to provide programmers with a guaranteed
            level of functionality.

    2.      Programmers can work from a formal definition of the level of
            functionality which they can expect to be available on any IMP
            system.

    The intent is to allow programmers to write programs which can be
    guaranteed to operate on a wide variety of computer systems without
    requiring source program modifications.

    1.1 Conventions

       To make this document more consistent and readable, a number of
    conventions are held to throughout.  These conventions are described
    here in two parts.  Firstly, the textual conventions used to express
    both formal and informal concepts are described, along with the
    conventions used to represent IMP program fragments.  Secondly, a
    section is devoted to the syntactic metalanguage used to express
    grammars in the few cases where this is necessary.

    1.1.1 Textual Conventions

       Several textual conventions are used within this document to make it
    more readable.  The first or defining use of a term will be underlined
    as in the following (fictitious) example about "phantom circuits":

    These two pairs of wire, termed the physical or side circuits, are
    effectively in parallel from the point of view of the phantom circuit.

       Some other conventions are best seen by reference to the following
    example IMP program:

             begin
                integer Number Of Times = 1000, Counter
                for Counter = 1, 1, Number Of Times cycle
                   Print String("Hello, world")
                   New Line
                repeat
             end

    From this program, we can see that the convention for representing IMP
    keywords is by the use of underlining, as in begin.  We also use this
    convention in text which discusses IMP program fragments: thus, we might
    discuss the integer data type (the one in the IMP language) as opposed
    to mathematical integers (members of a particular infinite set) with no
    ambiguity.

       As can be seen, identifiers in IMP program text will be written in
    mixed case.  References to such identifers in discussions such as this
    will be given in upper case in order to make the identifier stand out
    from the surrounding text.  For example, discussions of the above
    program would always talk about the integer variables COUNTER and NUMBER
    OF TIMES.

       Where this standard makes reference to some other publication, the
    reference will take the form [xxxxxx].  These references are collected
    and given in full in an appendix to this standard.

    1.1.2 Standard Syntactic Metalanguage

       At certain points in this standard, it is convenient to describe the
    behaviour of a procedure by reference to the grammar of the objects it
    processes or generates.  For example, the description of a procedure
    which converts a textual (string) denotation of an integer value into
    the corresponding integer representation will be specified by defining
    the syntax of the character stream contained in the string.  Many
    syntactic metalanguages are available to describe grammars in this way,
    Backus-Naur Form (also known as Backus-Normal Form or BNF) and Van
    Wijngaarden two-level grammars being perhaps the best known.  The
    syntactic metalanguage used in this standard is that defined by the
    British Standards Institution in [BS6154].

       This particular metalanguage was chosen for three reasons.  Firstly,
    it is the only syntactic metalanguage have a formal standard dedicated
    to its definition (although many others have appeared as part of other
    standards).  Secondly, it is reasonably easy to understand even by
    people with little prior experience in interpreting formal
    specifications.  Lastly, it is a representation designed for computer
    processing, so that it uses only a single typeface and no special
    characters, so that it could be included in this standard without
    problems of reproduction.

       A full description of the standard syntactic metalanguage can be
    found in [BS6154] and an introductory text describing its use is
    available as [SCO83].  For those without access to these documents, a
    brief description of the more important features of the metalanguage
    will now be given.

       Terminal strings of the language are given enclosed in double quotes.
    No significance is given to letter case or "white space" except within
    terminal strings.  Non-terminal identifiers follow the syntax for IMP
    identifiers, i.e. a mixture of letters and digits of any length.
    Concatenation is indicated by commas and alternatives by vertical bar
    '|'.  Definition of non-terminals is performed by the equals operator,
    with the end of a definition indicated by a semi-colon.  Optional
    sequences are enclosed by square brackets '[' and ']' while 0-or-more
    repetitions are achieved by enclosing the sequence in braces '{' and

    '}'.  A simple example of the above facilities is given in the following
    definitions:

          sign         = "+" | "-" ;
          octal digit  = "0" | "1" | "2" | "3" |
                         "4" | "5" | "6" | "7" ;
          octal number = "8_", octal digit, { octal digit } ;
          signed octal = [sign], octal number;

    1.2 Terminology

       For the purpose of this standard, the following words and phrases are
    taken to have the meanings indicated in this section.

    1.2.1 Implementation Defined

       Operations or results which are implementation defined may vary
    between implementations, but must be defined in a document accompanying
    each implementation.  Each implementation defined item in this standard
    is flagged by a reference number of the form "DEFnnnn" which uniquely
    identifies the item.  An appendix to this standard lists all
    implementation defined reference numbers along with the operations or
    results to which they refer.  This can be used by implementors or
    validators as a checklist to an implementation's conformance with this
    standard.  Programs may only assume particular definitions of
    implementation defined items if portability is not an object, for
    example in the case of system-specific utilities.

    1.2.2 Implementation Dependent

       Operations or results which are implementation dependent may vary
    between implementations and may also vary within an implementation
    depending on context.  Implementations need not define implementation
    dependent results or operations.  However, for convenience these items
    are given reference numbers in the same way as implementation defined
    items but with the form "DEPnnnn".  Again, a checklist of these items is
    included as an appendix to this standard.  Programs may never assume
    particular definitions of implementation dependent items as these may
    change during the evolution of the implementation in question, during a
    cross-system porting activity or at the discretion of the compiler in
    particular circumstances.

    1.2.3 Error

       The execution of operations designated in this standard as errors
    should never be attempted during the execution of a program.  The effect
    of an error condition on a program is not defined by this standard.
    Reference numbers for error conditions take the form "ERRnnnn" and a

    checklist of all error conditions appears as an appendix to this
    standard.

    1.3 Conformance

       As stated above, the aim of the IMP Core Environment Standard is to
    allow a programmer to ensure that a program can be freely ported from
    one IMP system to another without source modifications.  Clearly, this
    can be achieved only if both the program concerned and the proposed
    target systems are compatible; this will be guaranteed if program and
    systems conform to this definition.

    1.3.1 Program Conformance

       A particular program may be said to conform to this standard if all
    of the following conditions are met:

    1.      The program assumes as predefined only those procedures which
            are defined as being mandatory by this standard.

    2.      The program assumes the functionality of predefined procedures
            to be as defined in this standard, in particular avoiding any
            operation which is defined to be an error by this standard.

    3.      The program assumes the definitions of implementation defined
            items only within the minimum definitions required by the
            appropriate checklist appendix to this standard.

    4.      The program does not assume a particular definition of any of
            the implementation dependent items listed in the appropriate
            checklist appendix to this standard.

    1.3.2 Implementation Conformance

       An implementation may be said to conform to this standard if all of
    the following conditions are met:

    1.      All identifiers designated by this standard as pre-defined are
            available as pre-defined in the implementation, with the source
            language semantics and behaviours under non-error conditions
            defined for them in this standard.  This behaviour must hold
            both for the default use of the implementation and for any
            "optimising" or "non-checking" modes of use, although the
            behaviour of the implementation under error conditions may vary.

    2.      All identifiers designated by this standard as being defined
            through the use of specific from IMP include File statements
            must become available if such a statement is contained in the
            program, and if so the identifiers must become available with
            the source language semantics and behaviours under non-error
            conditions defined for them in this standard.  This behaviour

            must hold both for the default use of the implementation and for
            any "optimising" or "non-checking" modes of use, although the
            behaviour of the implementation under error conditions may vary.

    3.      Identifiers not covered by items 1. or 2. above must not be
            available as pre-defined in the implementation without a method
            being available to have the implementation reject use of such
            identifiers as non-standard.

    4.      The implementation must be accompanied by a document which
            describes the effect of each error condition listed in the
            appropriate checklist appendix to this standard.  It is
            permissable for the document to state that any particular error
            condition will cause effects which are implementation dependent.

    5.      The implementation must be accompanied by a document which
            describes the particular definitions used by the implementation
            for each implementation defined item listed in the appropriate
            checklist appendix to this standard.

       As well as the documents mentioned above, an implementation may (as a
    matter of courtesy) be accompanied by a document which describes some or
    all of the definitions used by the implementation for each
    implementation dependent item as listed in the appropriate checklist
    appendix to this standard.  It should be stressed that this document is
    not required as a part of an implementation's conformance but simply as
    a convenience to the more inquisitive or demanding of its users.