J3/04-407 Date: 15 Oct 2004 To: J3 From: Richard Maine Subject: Simplified KIND selection - Specs and illustrative syntax References: J3/04-270 INTRODUCTION This paper proposes specs and illustrative syntax for simplified kind selection. The proposal for this feature was originally submitted as 04-270 and garnered strong support, as documented in 04-302. It appears to have beeen combined with 04-121 as a single entry in 04-370r4. However, the paper alleging to "complete" that combined proposal makes no mention at all of the subject material. I find it a bit unfortunate that the combination of these two proposals seems to have resulted in the disappearance of the one that had substantially stronger support. This probably reflects the unfortunate fact that presence of the advocate at the meeting is a bigger driver than many other factors. I suggest that the current attempts to craft edits are not only premature, but are detrimental to the job of deciding on a feature set. Specs, and perhaps even syntax, can help in making that decision, but I view edits at this stage as a distracting detriment. I'd say that they were a waste of time because so many of them are not in good enough shape to be real edits, but I think that it is too generaous to label them as a waste; I think them to be an active detriment. Therefore, this paper does not propose edits, but restricts itself to specs and illustrative syntax. I am not wedded to the particular specs proposed here if J3 prefers a different direction. Moving the proposal forward to at least specs just seems more likely to get results than would a reminder that the original proposal got "lost". REQUIREMENTS Requirements were outlined in 04-270. In short review, the requirement is to provide a simplified means to select the most commonly desired real and integer kinds. SPECIFICATIONS Several possible approaches were outlined in 04-270. I propose that we adopt the approach that is intermediate in complexity, namely that the standard define named constants for the most commonly desired real and integer kinds. The approach of standardizing specific kind values would be simpler, but seems overly restrictive. It also raises issues of compatibility with existing code and compilers, which would turn this otherwise simple proposal into a much larger issue. The edits might be small, but the implications would not be. The approach of extending the selected_*_kind intrinsics or adding new similar ones would provide more flexibility and lessen the confusions involved in translating user requirements into decimal digits of precision. However, it does not do much about simplification, which is the primary requirement here. The approach of standardizing some named constants seems adequately simple without being restrictive or raising compatibility issues. It also has the advantage of being completely trivial to implement. My proposal is restricted to kinds with exact sizes. Adding too many options would increase the complexity of the choice to be made by users and would result in issues of interoperability of codes where different users made different choices of how to specify the kinds. Note that the existing selected_*_kind intrinsics provide the capability of specifying minimum requirements and could be extended in many ways (although that is not proposed here). Exact sizes are the simplest and most commonly requested requirement, and one that the standard currently provides no facility for (except in C interop, which has it only for integers - nor for reals). I also restrict the proposal to integers and reals because they are the common cases. User specification of specific sizes for logical kinds is rare (and even more rare when you rule out the cases where logical is being used as a synonym for unsigned integer, which is a nonstandard and nonportable practice anyway). User specification of character kinds is also rare. Therefore, I propose that the specifications be: The standard will specify the names of several named constants in the ISO_FORTRAN_ENV intrinsic module. These named constants will have kind values for the representations described below. Named constants provided will be for the kinds of integers whose storage sizes are exactly 8, 16, 32, and 64 bits, and for the kinds of reals whose storage sizes are exactly 32, 64, and 128 bits. Additionally, named constants will be provided for the kinds of default integer, default real, and double precision real. If the processor supports more than one representation with the specified size, it is processor-dependent which of those representations the named constant corresponds to. If the processsor does not support a particular representation, the value of the corresponding named constant will be one of two negative values specified by the standard. If the processor does not support a representation with the exact size requested or with any larger size, the value shall be -1. If the processor does not support a representation with the exact size requested, but does support a representation with a larger size, the value shall be -2. This proposal does not require the compiler to support any particular kind. Nor does this proposal specify the kind values, which remain processor-dependent. ILLUSTRATIVE SYNTAX This syntax suggestion is purely illustrative for now. It seems too early to debate exact names when it is not yet decided what things need names and what the meaning would be. The exact names are really the only syntax matter relevant to the proposed specifications. If the above specifications are accepted, a possible set of names is: int8_kind, int16_kind, int32_kind, int64_kind real32_kind, real64_kind, real128_kind int_default_kind, real_default_kind, real_double_kind