From jkr@jkr.cc.rl.ac.uk Wed May 2 10:35:13 2001 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 KAA58856 for ; Wed, 2 May 2001 10:35:13 +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 JAA20500 for ; Wed, 2 May 2001 09:35:28 +0100 Received: (from jkr@localhost) by jkr.cc.rl.ac.uk (8.8.8+Sun/8.8.8) id JAA01427 for SC22WG5@dkuug.dk; Wed, 2 May 2001 09:37:34 +0100 (BST) Date: Wed, 2 May 2001 09:37:34 +0100 (BST) From: John Reid Message-Id: <200105020837.JAA01427@jkr.cc.rl.ac.uk> To: SC22WG5@dkuug.dk Subject: Interp F90/196 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" WG5, Here is a revised draft response for interp. F90/196. Comments, please, preferably to me in private, before I send this to J3. John Reid. J3/01-xxx Date: 2 May 2001 To: J3 From: John Reid Subject: Interpretation F90/000196 (Inaccessibility of intrinsic procedures) Here is a new draft response. I append the present draft and the comments on it that were made with the J3 ballot in 1995. I have altered the start of the question to reference the text of the 1995 standard. I have removed the second edit since it is over restrictive and the rules are already laid out in 12.3.2.1, which is referenced. NUMBER: F90/000196 TITLE: Inaccessibility of intrinsic procedures KEYWORDS: intrinsic procedure, INTRINSIC attribute, generic identifier, names class DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Note 14.2 states: "An intrinsic procedure is inaccessible in a scoping unit containing another local entity of the same class and having the same name. For example, in the program fragment SUBROUTINE SUB ... A = SIN (K) ... CONTAINS FUNCTION SIN(X) ... END FUNCTION SIN END SUBROUTINE SUB any reference to function SIN in subroutine SUB refers to the internal function SIN, not to the intrinsic function of the same name." Are the following two comments about this text correct? (1) The example is not strictly correct because the resolution of the procedure reference "SIN" depends on the contents of the first "...": (1a) If "..." does not contain an "INTRINSIC SIN" statement, the behavior is as specified: In SUB, the name SIN is established specific due to condition 14.1.2.4 part (2b), it is not established generic, and the internal function SIN is referenced due to 14.1.2.4.2 part (3). (1b) If "..." does contain an "INTRINSIC SIN" statement, SIN is established specific as above, but also established generic due to condition 14.1.2.4 (1b). So the reference is resolved according to 14.1.2.4.1 part (2): the intrinsic function SIN is called. ( At least if there is a suitable specific function for data ) ( object K. If not, the reference is resolved according to ) ( 14.1.2.4.1 (4) which also requires a consistent reference. ) (2) The first sentence of the cited text is wrong (incomplete), because it does not consider the case of generic identifiers: * Intrinsic procedures are local entities of class (1). * Generic identifiers are local entities of class (1). * Various instances in the standard indicate that it is possible to extend the generic interface of intrinsic procedures. Consequently, in the example MODULE my_sin CONTAINS LOGICAL FUNCTION lsin (x) LOGICAL, INTENT(IN) :: x ... END FUNCTION lsin END MODULE my_sin SUBROUTINE sub USE my_sin INTERFACE SIN MODULE PROCEDURE lsin END INTERFACE SIN ... END SUBROUTINE sub the intrinsic procedure SIN remains accessible in SUB although that scoping unit contains another local entity of class (1) named SIN. ANSWER: Comment 1 is incorrect. See the answer to (1b). Comment 1a is correct. Comment 1b is incorrect. SIN is a local name for the internal procedure, which is a specific procedure, and adding an "INTRINSIC SIN" statement is prohibited by 14.1.2, 3rd paragraph. Comment 2 is correct. The edit removes the contradiction. EDIT: In section 14.1.2, NOTE 14.2, [276:10], change "having the same name" in the first sentence to "having the same name, except when the other local entity and the intrinsic are both generic procedures". SUBMITTED BY: Michael Hennecke (hennecke@rz.uni-karlsruhe.de) HISTORY: 95-252 m135 submitted 95-281 m135 response WG5 approved (N1161) 96- m136 X3J3 ballot failed 16-0, possible error in 2nd edit, WG5 approval removed. Barber edit applied ----------------------------------------------------------------------------- Old answer ANSWER: Comment 1 is incorrect. See the answer to (1b). Comment 1a is correct. Comment 1b is incorrect. SIN is a local name for the internal procedure, which is a specific procedure, and adding an "INTRINSIC SIN" statement is prohibited by 14.1.2, 3rd paragraph. Comment 2 is correct. Edits to remove the contradiction are included below. EDITS: 1.In section 14.1.2, 4th paragraph [241:36], change "having the same name" in the first sentence to "having the same name, except when the other local entity and the intrinsic are both generic procedures" 2.In Section 14.1.2, 3rd paragraph [241:33], change "in the case of" to "when both are" ------------------------------------------------------------------------------- Ballot comments ------------- 000196 Inaccessibility of intrinsic procedures 196 Ywc Barber After the program fragment in the question insert the text "any reference to function SIN in subroutine SUB refers to the internal function SIN, not to the intrinsic function of the same name" This completes the sentence preceding the fragment that otherwise is left dangling. 196 N Hennecke I agree with the answer to (2), and edit 1. I do not agree with the answer to (1b), and edit 2 which was made to justify that answer is inadequate: The 3rd paragraph of 14.1.2 originally reads "in the case of generic names (12.3.2.1)". The last paragraph of the quoted section 12.3.2.1 contains the sentence "A generic name may be the same as any one of the procedure names in the interface block, or the same as any accessible generic name." Edit 2 introduces a restriction to the second half ("when both are generic names"). This is a change of the original meaning of 14.1.2, which (in my opinion) addresses the possibility of the first half of the above quotation from 12.3.2.1. If accepted, edit 2 would invalidate the use of a name both as a generic identifier and as the name of a specific procedure in that interface block. Edit 2 should be withdrawn or modified to include the case of "a name used as a generic identifier and as the name of a specific procedure in that interface block". This does not always prohibit the appearance of an "INTRINSIC SIN" stmt, there are a few more holes. I'd prefer to delete the "..." line in [007r1,272:10] and defer that discussion to a F95-interp. 196 Y Hirchert I took special care in looking at the answer to 1b in light of the Hennecke response, but I could find nothing wrong with the answer. [To amplify on that answer, a name is allowed to be both generic and specific in a scoping unit only if the specific is part of the generic, and this was not the case in 1b.] ------------- Fortran 95 edits listed for defect item 196 F95-196 N Hennecke See my 196 comment. F95-196 Y Hirchert See comments under defect item 196