$a include=template_file

$n$lm
IMP Core Environment Standard
$b2$lm
Section 1: Introduction
$a sectno=1; pageno=1
$a indent=0

$b2$v5$p 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:

$a indent=1
$b$t0 1$. $t Implementors of
   new IMP systems can work from a formal definition in order to provide
   programmers with a guaranteed level of functionality.
$b$t0 2$. $t
   Programmers can work from a formal definition of the level of
   functionality which they can expect to be available on any IMP system.
$a indent=0

$b$v5 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.




$b4$v5$l
1.1 Conventions
$p 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.




$b4$v5$l
1.1.1 Textual Conventions
$p 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":
$a left<=+10; line<=-20
$b These two pairs of wire, termed the %physical or %side %circuits, are
effectively in parallel from the point of view of the phantom circuit.
$a left>; line>

$v5$p Some other conventions are best seen by reference to the following
example IMP program:
$b$v7$l0
         %begin
            %integer Number Of Times = 1000, Counter
            %for Counter = 1, 1, Number Of Times %cycle
               Print String("Hello, world")
               New Line
            %repeat
         %end
$b 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.

$v5$p 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.

$v5$p 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.



$b4$v5$l
1.1.2 Standard Syntactic Metalanguage
$p 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].

$p 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.

$p 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.

$p 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:
$b$v5$l0
      sign         = "+" | "-" ;
      octal digit  = "0" | "1" | "2" | "3" |
                     "4" | "5" | "6" | "7" ;
      octal number = "8$_", octal digit, { octal digit } ;
      signed octal = [sign], octal number;
$b0






$b4$v5$l
1.2 Terminology
$p For the purpose of this standard, the following words and phrases are
taken to have the meanings indicated in this section.

$b4$v5$l
1.2.1 Implementation Defined
$p 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.

$b4$v5$l
1.2.2 Implementation Dependent
$p 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.

$b4$v5$l
1.2.3 Error
$p 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.



$b4$v5$l
1.3 Conformance
$p 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.

$b4$v5$l
1.3.1 Program Conformance
$p A particular program may be said to conform to this standard if
all of the following conditions are met:

$a indent=1

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

$b$t0 2$. $t
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.

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

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

$a indent = 0





$b4$v5$l
1.3.2 Implementation Conformance
$p An implementation may be said to conform to this standard if all of the
following conditions are met:

$a indent=1

$b$t0 1$. $t
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.

$b$t0 2$. $t
All identifiers designated by this standard as being
defined through the use of specific
_f_r_o_m$ IMP$ _i_n_c_l_u_d_e$ 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.

$b$t0 3$. $t
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.

$b$t0 4$. $t
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.

$b$t0 5$. $t
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.

$a indent=0

$p 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.

$a indent=1