*line 1: Unknown output type = >$A include=template_file 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 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. 14-1 * 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. 14-2 End of input file Program stopped