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.