IMP Core Environment Standard


                   Section 14: Language Implications
       *** WILL BE SHIFTED OUT OF STANDARD AS OF NEXT EDITION ***

   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.


*       language character set

           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?}.


*       floating point

           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 real, 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.


*       basic signal mechanism

           The I/O definitions here use an event trap to define end of
        input.  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.


*       definition of string data types

           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.


*       General names

           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:

            name X
            byte name B
            B == X


*       RECORD=0

           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.


*       fancy include statement

        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.


* range of integer values

           This definition now assumes a guaranteed minimum integer,
        short and byte range as follows:

      byte     [0 .. 255]                   {see DEF0003}
      short    [-32767 .. 32767]            {see DEF0004}
      integer  [-2147483647 .. 2147483647]  {see DEF0005}

        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.


* general map used in section 8 for NEW