From jkr@jkr.cc.rl.ac.uk Tue Mar 28 14:48:30 2000 Received: from nameserv.rl.ac.uk (nameserv.rl.ac.uk [130.246.135.129]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id OAA16145 for ; Tue, 28 Mar 2000 14:48:30 +0200 (CEST) (envelope-from jkr@jkr.cc.rl.ac.uk) Received: from jkr.cc.rl.ac.uk (jkr.cc.rl.ac.uk [130.246.8.20]) by nameserv.rl.ac.uk (8.8.8/8.8.8) with ESMTP id NAA19478 for ; Tue, 28 Mar 2000 13:48:20 +0100 Received: (from jkr@localhost) by jkr.cc.rl.ac.uk (8.8.8+Sun/8.8.8) id NAA11234 for SC22WG5@dkuug.dk; Tue, 28 Mar 2000 13:49:24 +0100 (BST) Date: Tue, 28 Mar 2000 13:49:24 +0100 (BST) From: John Reid Message-Id: <200003281249.NAA11234@jkr.cc.rl.ac.uk> To: SC22WG5@dkuug.dk Subject: Interpretation 003 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: 28th March 2000 To: J3 From: John Reid Subject: Interpretation 003 Here are drafts for the ANSWER and EDITS sections of 003. Also, I propose that the addendum be removed. For your convenience, the current 003 is attached. ANSWER: Intrinsic concatenation is defined only for character operands with the same type parameter value. This is stated clearly (90: 8-9): 'For the character intrinsic operator //, the kind type parameters shall be the same'. There is a need for a similar restriction at this point for relational intrinsic operators with character operands. The words at the end of the next paragraph (90: 12) actually suggest that there are relational intrinsic operations for character operands of different type parameter values that are not character relational intrinsic operations. The word 'requiring' in the last sentence in the note in Table 7.1 should be changed since all the intrinsic operators with character operands require their operands to have the same kind type parameter. EDITS: Page 89, Table 7.1, penultimate line (89:38). Change 'requiring' to 'with'. Page 90, line 9. Add 'For the relational intrinsic operators with character operands, the kind type parameters shall be the same'. Page 90, line 12. Delete 'and have the same kind type parameter value'. ------------------------------------------------------------------------------- NUMBER: 000003 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. -------------------------------------------------------------------------------