07-159 To: J3 From: Dick Hendrickson Subject: Clause 13; Add type kind number arrays Date: 2007 February 06 References: J3/07-007 A straw vote at meeting 178 strongly favored adding arrays containing the supported kind values for all of the intrinsic types except BITS. The straw vote called for the values to be in "non-decreasing order by storage size." In a private communication, Malcolm pointed out some problems with this requirement. It shoots release to release compatibility in the foot. What happens "next year" when a vendor gets talked into providing a one-byte logical type? Suddenly, the array values change and recompilation might be forced. Secondly, it's likely that an (unthinking) programmer will expect REAL_KINDS(2) to be double precision. That's true on processors that only support two kinds. But, not true for processors that support several formats for their real type. So, I've ignored the storage order part of the straw vote and used processor dependent instead. Malcolm also pointed out an additional problem with using arrays. It's reasonable for processors to eventually support unlimited precision integers or reals. Right now, there are various packages available for higher precision. There're somewhat awkward to use. Bt specifying an array of supported kind values, we effectively prevent a processor from offering unlimited precision. We already acknowledge this problem by not having a BIT_KINDS array. INTEGER and REAL might have the same problem in the future. I believe we should revisit the second straw vote on paper 06/360R1 and reconsider the idea of a next_kind_value set of functions. Alternatively, we could add something like "The array size is processor dependent, however it must include all of the supported kinds that have a precision or range less than or equal to 5 times the precision or range of default real" to both the integer and real arrays. This would allow a processor to eventually support unlimited precision without needing to also support an unlimited size array. If we go ahead with the array approach, the following are the proposed edits to 07/007 -------------------- Insert the following paragraphs in alphabetical order in 13.8.2 [436] 13.8.2.2a CHARACTER_KINDS The values of the elements of the default integer named constant CHARACTER_KINDS are the kind values supported by the processor for variables of type character. The order of the values is processor dependent. The size of the array is the number of character kinds supported. [437] 13.8.2.7a INTEGER_KINDS The values of the elements of the default integer named constant INTEGER_KINDS are the kind values supported by the processor for variables of type integer. The order of the values is processor dependent. The size of the array is the number of integer kinds supported. [438] 13.8.2.12a LOGICAL_KINDS The values of the elements of the default integer named constant LOGICAL_KINDS are the kind values supported by the processor for variables of type logical. The order of the values is processor dependent. The size of the array is the number of logical kinds supported. [438] 13.8.2.14a REAL_KINDS The values of the elements of the default integer named constant REAL_KINDS are the kind values supported by the processor for variables of type real. The order of the values is processor dependent. The size of the array is the number of real kinds supported.