J3/97-239 Date: 15 October 1997 To: J3 From: Larry Rolison Subject: Interpretation Request: Ability to Overload the Character Operator // NUMBER: 3 TITLE: Ability to overload the character operator // KEYWORDS: overload, intrinsic, // DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress QUESTION: On page 89 of the Fortran 95 standard, the Note at the bottom of Table 7.1 states in part: For the intrinsic operators REQUIRING {emphasis not in standard} operands of type character, the kind type parameters of the operands shall be the same. Since there is only one intrinsic operator (//) that REQUIRES its operands to be of type character, one may conclude that the operands of the // operator MUST be of type character and MUST have the same kind type parameters. The last sentence of the first full paragraph on page 90 restates the above rule for intrinsic uses of // as follows: For the character intrinsic operator //, the kind type parameters shall be the same. Contrast this with the last sentence of the last paragraph of this section: A {character relational intrinsic operation} is a relational intrinsic operation where the operands are of type character and have the same kind type parameter value. >From the wording of this last sentence, one may conclude that if the kind type parameters are the same, then the relational operation is intrinsic but if the kind type parameters are NOT the same, then the relational operation is NOT intrinsic and must be defined via a user-provided function. Thus, it is possible for the character operands of a relational operator to have differing kind type parameter values. Now compare this to the following sentence from 7.1.4.2: For an expression // where and are of type character, the character length parameter is the sum of the lengths of the operands and the kind type parameter is the kind type parameter of , which shall be the same as the kind type parameter of . Note that there is no text or title to indicate that the description is only for intrinsic operators. There appears to be no way to overload the // symbol at all since the wording does not restrict the rule to the intrinsic interpretation of the operator (it appears in fact from the wording that once the operands are of type character, there can be no other interpretation other than intrinsic). This is surely not what was intended. The wording should be redone to more closely resemble that for the character relational operators such that if the operands of // do not have the same kind type parameters, an overload is allowed (and the operator is not interpreted as being intrinsic). (See also 7.2.2 Character intrinsic operation.) Suggested edits: 1. Delete the last sentence of the first full paragraph on page 90. 2. Add the following sentence to the last paragraph of 7.1.2: A {character concatenation intrinsic operation} is a concatenation operation where the operands are of type character and have the same kind type parameter value. 3. In the second sentence of the third paragraph of 7.1.4.2, insert "and have the same kind type parameter value" ahead of the first comma. ANSWER: EDITS: SUBMITTED BY: Larry Rolison HISTORY: J3/97-239 m143 submitted Addendum: An email response from Richard Maine when I pointed the inconsistency out to him: Date: Tue, 8 Jul 1997 09:00:25 -0700 To: Larry Rolison Subject: Re: Another f2k edit I [also] noticed the difference in terminology ... My reading is that the difference is just sloppily inconsistent wording (which should be fixed for f2k) rather than a real difference between concat and the char relationals. I suspect that it is just the *intrinsic* concat that "requires" kind agreement - if it doesn't hold, then you don't have the intrinsic concat, but could still overload one. In other words, even though the wording is different, I think they are trying to say the same thing. I certainly can't think of any reason why they *should* be different. But I haven't really researched it - nor do I have time to right now. ---------------------------------------------------------------------------- Larry Rolison lrr@cray.com Cray Research, A Silicon Graphics Company 655F Lone Oak Drive Eagan, MN 55121 ----------------------------------------------------------------------------