J3/97-180 Date: May 14, 1997 To: J3 From: Interval 1 Subject: Directions for interval optionality References: Subgroup has identified the following general possibilities for handling a program containing interval syntax on a processor that does not support interval arithmetic. 1. ("Fortran IEEE style") The program must compile, but there is a runtime test (such as an intrinsic function) that returns whether the processor supports interval arithmetic. Pro: (a) Compiles everywhere; (b) easy for consumer Con: (a) Greater implementation burden. (b) Potentially confusing (The vendor does not provide a warning, error committal and notification therefore are too separated.) 2. Handling is processor-dependent. (The processor may or may not give a diagnostic; what the processor actually does with the interval syntax is not specified; indeed whether compilation succeeds is left unspecified.) Pro: Easy to write the standard. Con: (a) Hard on users, since difficult to write portable code (requires technology outside 1539-1, such as COCO to write portable code). (b) Standard-conforming programs may or may not compile on a standard-conforming processor. 3. The processor must diagnose non-support at compilation time (constraint-like). Pro: Users cannot be surprised at runtime. (Oversimplification: Users can't get a wrong answer.) Con: (a) There is no single source-code portability. (b) It may not be possible to check interval syntax on a machine that does not support interval arithmetic. Discussion: Subgroup uniformly recommends (3). We may need some input on whether it should truly be a constraint, or merely be a required failure (if there is a difference in implementation effort). Our reasoning is essentially as follows: (1) is a burden for both users and implementers. The "nightmare" scenario is a processor that chooses to treat intervals as reals (interval constants as the midpoint, etc.) *and* a buggy user program that fails to check at runtime. The result *appears* "ok" but isn't really an interval result (so containment isn't required, etc.). While one would hope that such a vendor would have produced a diagnostic warning, and no user would ever fail to write the appropriate check, life is often imperfect. (2) maximizes the burden on consumers. Potentially mistakes might not be diagnosed (return of the nightmare). (3) provides maximum protection for users, and provides "failure" information earliest (when it's easiest to cope with from a human factors perspective). It is subgroup's hope that this is not seen as an unreasonable implementation burden.