                         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