From jkr@jkr.cc.rl.ac.uk Fri May 4 18:01:15 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 SAA73174 for ; Fri, 4 May 2001 18:01:14 +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 RAA06246 for ; Fri, 4 May 2001 17:01:31 +0100 Received: (from jkr@localhost) by jkr.cc.rl.ac.uk (8.8.8+Sun/8.8.8) id RAA05057 for SC22WG5@dkuug.dk; Fri, 4 May 2001 17:03:38 +0100 (BST) Date: Fri, 4 May 2001 17:03:38 +0100 (BST) From: John Reid Message-Id: <200105041603.RAA05057@jkr.cc.rl.ac.uk> To: SC22WG5@dkuug.dk Subject: Re: Interp F90/205 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" WG5, Here is a draft response for interp. F90/205. Comments, please, preferably to me in private, before I send this to J3. John Reid. J3/01-xxx Date: 4 May 2001 To: J3 From: John Reid Subject: Interpretation F90/205 (Restrictions on EXTERNAL) Interpretation F90/205 is not a new interpretation. It failed its J3 ballot, with 1 NO vote against 14 YES votes and one YES with comments. The present response and the ballot comments (00-329) and are appended for your convenience. This paper provides a new draft that does not alter the main conclusion, but includes a discussion that takes account of the reasons given for the NO vote and includes an edit. I have altered the question to refer to Fortran 95, as requested in the YES comment. .................................................. NUMBER: F90/000205 TITLE: Restrictions on EXTERNAL KEYWORDS: EXTERNAL attribute, external subprogram DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Let the following two procedures not be contained within a main program, a module, or another subprogram. In this case they are <>s by the definitions of Fortran 95, section 2.2: SUBROUTINE subroutine_subprogram ( ) ! ... END SUBROUTINE subroutine_subprogram FUNCTION function_subprogram ( ) INTEGER :: function_subprogram ! ... END FUNCTION function_subprogram They are also external procedures, since F95 section 2.2.3.1 (and 12.1.2.2) states that "An <> is a procedure that is defined by an external subprogram or by means other than Fortran." External functions may be given the EXTERNAL attribute in form of an (R503), external procedures may be given the EXTERNAL attribute by an (R1208). QUESTION 1: Is it correct that the current definitions in F95 do allow the EXTERNAL attribute to be specified for the name of the external subprogram in which such a declaration is contained? In other words, is the following code standard-conforming? SUBROUTINE subroutine_subprogram ( ) EXTERNAL subroutine_subprogram ! ... END SUBROUTINE subroutine_subprogram FUNCTION function_subprogram ( ) INTEGER, EXTERNAL :: function_subprogram ! ... END FUNCTION function_subprogram QUESTION 2: If the answer to question 1 is YES: was this the intention, or should it be prohibited that an EXTERNAL attribute is given to the name of an external subprogram by declarations within that subprogram? ANSWER: 1. No, the EXTERNAL attribute may not be specified for the name of an external procedure defined by the subprogram, but this is not said explicitly. An edit is supplied to correct this. 2. Not applicable. DISCUSSION: The final paragraph of subclause 12.3.2.2 states [197:30-32] 'A name that appears in an EXTERNAL statement in a given scoping unit ... shall not also appear as a specific procedure name in an interface block in the scoping unit nor in an interface block that is accessible to the scoping unit.' The intention was to disallow the EXTERNAL attribute for a procedure with an explicit interface. Subclause 12.3.1 states [193:1-2]; 'The interface of a recursive subroutine or a recursive function with a separate result name is explicit within the subprogram that defines it.'. It was intended that the EXTERNAL attribute should not be permitted for these cases since the interface is explicit. Only in the cases mentioned in the previous paragraph may an external procedure name be used as a procedure name in the interior of the subprogram that defines it. In other cases, there would be no value in specifying the EXTERNAL attribute. EDIT: In subclause 12.3.2.2, add at the end of the first paragraph after R1208 [197:17] 'In an external subprogram, an EXTERNAL statement shall not specify the name of a procedure defined by the subprogram'. SUBMITTED BY: Michael Hennecke (hennecke@rz.uni-karlsruhe.de) HISTORY: 96- m136 submitted WG5/N1404 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed J3 letter ballot .................................................... Old draft response ANSWER: 1. No, the EXTERNAL attribute may not be specified for the name of an external subprogram within that subprogram. 2. Not applicable. DISCUSSION: Appearance of a name as the in a or the in a , that is not in an or a , explicitly specifies that the name is that of an external procedure and has the EXTERNAL attribute. The second constraint in 5.1 states "An entity shall not be explicitly given any attribute more than once in a scoping unit." Section 5.2 makes it clear that this applies to EXTERNAL statements. Therefore, the EXTERNAL statements in the example are duplicate specifications and so not standard-conforming. EDIT: None. .................................................... Ballot comments F90/000205 Restrictions on EXTERNAL DickH's YES comment on F90/000205 COMMENT: First line of Question 1 refers to F90, we should change to F95 Henry's NO vote on F90/000205 Although we agree that it should not be possible to specify the EXTERNAL attribute for an external procedure in the scope of the subprogram that defines that procedure, we do not agree that the existing text of the standard makes that clear. In particular, the response suggests that appearance of a name as the in the or in the of a external subprogram causes the name to be considered to be the name of an external procedure, and gives it the external attribute. We agree that the name is considered to be an external procedure, but that does not imply that it has the external attribute. For example, the following program unit is not standard conforming. It is clear in this example that SUB1 is an external procedure, but it does not have the external attribute (or an explicit interface), so it cannot appear as an actual argument. CALL SUB1 CALL SUB2(SUB1) END There is evidence that it was not the intent of the committee to permit the external attribute to be specified for an external procedure in the scope that defines the procedure. Consider 12.5.2.2 [206:41-42], which states: Constraint: If RESULT is specified, the function-name shall not appear in any specification statement in the scoping unit of the function subprogram. When a result clause appears on a function statement, there is no way for the user to specify the external attribute for the function name, even though the name is unambiguously the name of the function in that case, and not the name of the result variable. However, there does not appear to be a general prohibition.