$a include=template_file

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

$lm
*** WILL BE SHIFTED OUT OF STANDARD AS OF NEXT EDITION ***

$p Much of this library definition is given in terms of fragments of IMP code,
commonly procedure definitions.
The precise definition of procedures in the library is therefore dependent
on the definition of IMP itself: this section attempts to pinpoint some of the
more important assumptions being made.

$a indent=1




$b4$v5$t0 * $t language character set
$p The language character set is assumed to be the 7-bit ISO/ASCII character
set, with all non-graphic characters
except "new line" (NL, value 10) treated as "white space". Reconsideration
of some parts of the document may have to be made if/when IMP moves to the new
ISO 8-bit character set {is this desirable anyway?}.




$b4$v5$t0 * $t floating point
$p The presence in this definition of procedures with %real parameters or
results implies that any conforming IMP system must include %real data
types. No assumption is made about a difference between %real and %long
_r_e_a_l, however, so they may turn out to be the same in some implementations.
The %long %real declarator must still be accepted even in single-precision
systems.




$b4$v5$t0 * $t basic %signal mechanism
$p The I/O definitions here use an %event trap to define %end %of _i_n_p_u_t.
For this code to work, the %signal mechanism must be present on any conforming
IMP system. In addition, the %signal number used for end of input must be the
same on all implementations.




$b4$v5$t0 * $t definition of %string data types
$p It might be good to define these as <byte><byte*N> contiguous in store.
Examples solicited of when it would be useful to guarantee this?
(PSR: file mapping) We could define
a record format with a %byte %array (0:N) in it to get the effect we currently
assume.




$b4$v5$t0 * $t General _n_a_m_es
$p It would be nice if the following were accepted, for example meaning that
READ would not have to be defined in terms of INTEGER(ADDR(N)) and so on:
$b$v6$l0
            %name X
            %byte %name B
            B == X
$b0




$b4$v5$t0 * $t RECORD=0
$p The definition of NIL is such that if RECORD=0 is defined as a bit-by-bit
clear of the storage area occupied by RECORD, any pointers in the record will
point to NIL. This means that everyone's programs (which assume this) are
guaranteed to work. It may mean that the compilers have to know about NIL as
a special on some machines to prevent a valid pointer to address 0 being used
rather than a true zero pointer.




$b4$v5$t0 * $t fancy %include statement
$b$v5 Places already assumed to exist in this standard are all in IMP: they
are EVENTS, TYPES and ARCHAISMS.
The definition of this feature is at present contained in section 15
of this standard.




$b4$v5$t0 * range of %integer values
$p This definition now assumes a guaranteed minimum
%integer, %short and %byte
range as follows:
$b$v5$l0
      %byte     [0 .$. 255]                   {see DEF0003}
      %short    [-32767 .$. 32767]            {see DEF0004}
      %integer  [-2147483647 .$. 2147483647]  {see DEF0005}
$b This is what is assumed by programs at present. A detailed definition of the
implications of all this will follow in a later edition.
For information, the reason for excluding in the GUARANTEED ranges of the other
value (-verybig, hex pattern 16$_80000000) which we expect in practice is to
leave our options open on 1's complement machines for now (they don't have the
extra value as they have a -0) until we have worked out whether such machines
are really completely incompatible with this standard or not. For now, we are
playing safe.



$b4$v5$t0 * general %map used in section 8 for NEW