11-207 To: J3 From: Stan Whitlock Subject: Results of the J3 interp letter ballot #23 Date: 2011 June 23 Here are the results of J3 letter ballot #23 on Fortran interpretations that officially closed 25-Mar-2011. The ballot is in J3 paper 11-156 for meeting #194. If I have transcribed a vote or a comment incorrectly, please let me know. J3 rep F03 F08 F08 F08 F08 F08 124 050 051 052 053 054 Malcolm Cohen no ballot received Robert Corbett C Y Y Y Y Y Bill Long Y Y Y Y Y Y Dan Nagle no ballot received Craig Rasmussen Y Y Y Y Y Y Van Snyder C C C C C C Stan Whitlock Y Y Y Y Y Y Jim Xia C N Y N Y Y Tobias Burnus C - - - - - where Y means "yes" C "yes with comment" N "no with comment" The comments for each interp are attached below in the same order as the table above. The summary of DRAFT results is as follows: F03 F08 F08 F08 F08 F08 124 050 051 052 053 054 C ? C ? C C Y = passed C = passed as amended F = Failed J3 letter ballot ? = To be decided by /interp at m195 The interps marked "C" pass with some minor fixes, as noted below. The interps below begin the process of specifying edits to 10-007r1 instead of 10-007. This process will be applied to all of the passed interps in 006A. The edited interps in their final form are attached and will appear in the next version 006A. /Stan ************************************************************************ F03/0124 Definition is poorly defined Robert Corbett's Comment on F03/0124: The new interpretation is a great improvement over the interpretation offered in ballot #22. While checking the assertion that the array and derived type cases follow from the definitions in Clause 16.6.1, I found an apparent oversight. Consider the program PROGRAM MAIN TYPE T TYPE(T), ALLOCATABLE :: P INTEGER I END TYPE TYPE (T) :: X, Y X%I = 2 Y = X END This program is not standard conforming because the variable X is referenced while it is undefined (see Clause 6.2, paragraph 2 and Clause 16.6.1, paragraph 4). Paragraph 4 of Clause 16.6.1 should permit a variable with an unallocated allocatable component to be defined. The standard as written does not allow X or Y to be defined. Please note that I approve of the interpretation and edits provided. I am merely observing that more work remains to be done. Van Snyder's Comment on F03/0124: I agree with Tobias Burnus that the types need to be sequence types, and COMMON should be spelled correctly. Since this is an F03 interpretation being applied to F08, the edits should be explicitly stated to refer to 10-007r1 (the page and line numbers remain unchanged from 10-007). Jim Xia'c Comment on F03/0124: In example3, the derived types, t1 and t2, should be both sequence types. Tobius Burnus' Comment on F03/0124: Unrelated to the question, but concerning the validity of the program: I would like to see in F03/0124 for example 3 a SEQUENCE or BIND(C) attributes for the types (due to C5101) and the change COMON -> COMMON. Result of ballot on F03/0124: The typos from Van, Jim, and Tobius were corrected. The edits now specify 10-007r1. F03/0124 passes as amended. F08/0050 Ordering requirements on definition of specification functions Van Snyder's Comment on F08/0050: The quotations in the "background" section from F08/7.1.12 and F08/7.1.11 need paragraph and page numbers. The one from 7.1.12 is 7.1.12p2, and the one from 7.1.11 is paragraphs 8 and 9. The page:line for the first one is correct, but for the second the page number is lacking. It is page 151 in both 10-007 and 10-007r1. The edits should be stated to refer to 10-007r1 (the page and line numbers remain unchanged from 10-007). Jim Xia's No vote on F08/0050: I don't see how the new paragraphs make improvements. The listed example is already prohibited by the two paragraphs being replaced. Result of ballot on F08/0050: Van's changes for 10-007r1 were made. /interp will decide the result of F08/0050. F08/0051 Pure procedure arguments with VALUE Van Snyder's Comment on F08/0051: The edit should be stated to refer to 10-007r1 (the page and line number remains unchanged from 10-007). Should the defect type be "clarification" instead of "erratum?" Result of ballot on F08/0051: The interp contains an edit - by definition, it is an erratum. The edits now specify 10-007r1. F08/0051 passes as amended. F08/0052 Private type-bound procedures Van Snyder's Comment on F08/0052: The reference for the quotation in the answer section should be 4.5.7.3p1, not just 4.5.7.3 (it's complete in the edit). The page:line number should be stated to refer to 10-007r1 (it remains unchanged from 10-007). Jim Xia's No vote on F08/0052: This is an incompatible change from F03. It is clear from F03 the overriding rules apply to the same binding name regarless its accessibility. Compiler has put extra work in supporting this. I would change my vote to yes if edits are added to Clause 1.6.2 indicating this as an incompatible change from F03. Result of ballot on F08/0052: The edits now specify 10-007r1. interp will decide the result of F08/0052. F08/0053 Restrictions on generic declarations, generic resolution Van Snyder's Comment on F08/0053: The background section refers to 12.4.3.4 on page 283 for the description of the characteristics that cause dummy arguments to be distinguishable. More precisely, the description is in 12.4.3.4.5p3 at [10-007r1:286:1-5], not page 283. C1214 is more precisely at [10-007r1:286:12-13]. The page:line numbers should be stated to refer to 10-007r1. Result of ballot on F08/0053: The edits now specify 10-007r1. F08/0053 passes as amended. F08/0054 Requirements for needing an explicit interface Van Snyder's Comment on F08/0054: The reference in the question part could more precisely be 12.4.2.2p1. it would be helpful to add [10-007r1:279:19-35]. Result of ballot on F08/0054: The edits now specify 10-007r1. F08/0054 passes as amended. ---------------------------------------------------------------------- NUMBER: F03/0124 TITLE: Definition is poorly defined KEYWORDS: definition DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the program: PROGRAM example1 TYPE T1 SEQUENCE INTEGER I, J END TYPE TYPE T2 SEQUENCE INTEGER I, J END TYPE TYPE(T1) X TYPE(T2) Y EQUIVALENCE (X, Y) X%I = 1 X%J = 2 PRINT *, X, Y END Q1. Is this program standard-conforming, and if so, what does it print? According to items (1) and (12) of 16.6.5, the assignment to X%I causes both X%I and Y%I to become defined. Similarly, the assignment to X%J causes both X%J and Y%J to become defined. Then, according to item (15) of 16.6.5, both X and Y become defined. However, according to 4.5.2.4, X and Y are types with different names, and therefore are of different type, thus according to 16.6.6 item (1) when X becomes defined Y becomes undefined, and vice versa. This appears to be a contradiction. Furthermore, consider PROGRAM example2 TYPE t INTEGER a,b END TYPE TYPE(t),TARGET :: x INTEGER,POINTER :: p x = t(1,2) p => x%a p = 33 PRINT *,x END PROGRAM According to the quoted text, the assignment to P is defining a variable of type INTEGER, and one that is associated (partially, via pointer association) with a variable of type T. That would seem to make X undefined according to item (1) of 16.6.6. Q2. Is example2 intended to be standard-conforming? Finally, consider MODULE ugly1 TYPE t1 INTEGER a,b END TYPE INTEGER w,z TYPE(t1) x COMMON/c/w,x,z END MODULE MODULE ugly2 TYPE t2 INTEGER c,d END TYPE TYPE(t2) y1,y2 COMMON/c/y1,y2 END MODULE BLOCK DATA COMON/c/i(4) DATA i/1,2,3,4/ END BLOCK DATA PROGRAM example3 USE ugly1 USE ugly2 ! At this point c is 1,2,3,4. y1 = t2(66,-6) PRINT *,w ! Is this ok? w = 0 PRINT *,y1 ! And is this ok? END PROGRAM This is similar to example1, except that we are defining a whole variable of sequence type at once, not by partial definition. Q3. Is example3 standard-conforming? ANSWER: A1. The program was intended to be standard-conforming. An edit is supplied to remove the apparent contradiction. The program should print something like " 1 2 1 2". A2. Yes, example2 is intended to be standard-conforming. An edit is supplied to remove the problem. A3. Yes, example3 is intended to be standard-conforming. An edit is supplied to remove the problem. DISCUSSION: The only interesting case of variable definition causing an associated variable to become undefined is using the old FORTRAN 77 data types; all the other intrinsic types are not permitted to be associated with variables of different type. We only need to get the scalar intrinsic case right, as the array and derived type cases then follow automatically from the definitions in 16.6.1. EDITS to 10-007r1: [455:4-10] Replace 16.6.6 item (1) entirely: "(1) When a scalar variable of intrinsic type becomes defined, all totally associated variables of different type become undefined. (1a) When a double precision scalar variable becomes defined, all partially associated scalar variables become undefined. (1b) When a scalar variable becomes defined, all partially associated double precision scalar variables become undefined." [455:36] Change "(1)" to "(1)-(1b)". {Fix reference.} SUBMITTED BY: Robert Corbett (via Van Snyder via Dan Nagle) HISTORY: 08-269 m185 F03/0124 submitted 10-245 m193 Draft answer - Passed by J3 meeting 11-129 m194 Failed J3 letter ballot #22 10-254 11-150 m194 Revised answer - Passed by J3 meeting 11-xxx m195 Passed as amended by J3 letter ballot #23 11-156 ---------------------------------------------------------------------- NUMBER: F08/0050 TITLE: Ordering requirements on definition of specification functions KEYWORDS: Specification expressions, specification functions DEFECT TYPE: Erratum STATUS: Passed by J3 meeting REFERENCE: F95/0030 BACKGROUND (can be skipped without significant loss): F95/0030 asked to consider the following program unit. MODULE MOD INTERFACE INT MODULE PROCEDURE F1, F2 END INTERFACE CONTAINS INTEGER PURE FUNCTION F1(I) INTEGER :: A(INT(1_4)), B(INT(1_2)) ! A(1), B(19) INTEGER, PARAMETER :: KIND = SIZE(A) ! KIND == 1 INTEGER(KIND), INTENT(IN) :: I F1 = 17 END FUNCTION F1 INTEGER PURE FUNCTION F2(J) INTEGER :: C(INT(2_4)) ! C(2) INTEGER, PARAMETER :: KIND = SIZE(C) ! KIND == 2 INTEGER(KIND), INTENT(IN) :: J F2 = 19 END FUNCTION F2 END MODULE MOD In processing the references to "INT(1_4)" and "INT(1_2)" in F1, the processor needs to determine whether the references are to the intrinsic function, INT, or to one of the specific procedures, F1 or F2. Determining that requires the processor to have determined the kind type parameter of the dummy argument J, of F2. In turn, that requires the processor to determine whether the reference to "INT(2_4)" is a reference to the intrinsic function, INT, or to one of the specific procedures, F1 or F2. Determining that requires the processor to determine the kind type parameter of the dummy argument I, which requires it to determine that "INT(1_4)" in F1 was a reference to the intrinsic function INT. After all this is determined, the processor can determine that the reference to "INT(1_2)" in the declaration of B in F1 is a reference to the specification function F2. According to F95/7.1.6.1 [97-007r2:94:38-41], "If an initialization expression includes a reference to an inquiry function for a type parameter or an array bound of an object specified in the same , the type parameter or array bound shall be specified in a prior specification of the . The prior specification may be to the left of the inquiry function in the same statement." or F03/7.1.7 [04-007:30-33] "If an initialization expression includes a specification inquiry that depends on a type parameter or an array bound of an entity specified in the same , the type parameter or array bound shall be specified in a prior specification of the . The prior specification may be to the left of the specification inquiry in the same statement, but shall not be within the same ." or F08/7.1.12p2 [10-007r1:152:22-25] "If a constant expression includes a specification inquiry that depends on a type parameter or an array bound of an entity specified in the same , the type parameter or array bound shall be specified in a prior specification of the . The prior specification may be to the left of the specification inquiry in the same statement, but shall not be within the same ." According to F95/7.1.6.2 [97-007r2:96:27-37], "A variable in a specification expression shall have its type and type parameters, if any, specified by a previous declaration in the same scoping unit, or by the implicit typing rules in effect for the scoping unit, or by host or use association. If a variable in a specification expression is typed by the implicit typing rules, its appearance in any subsequent type declaration statement shall confirm the implied type and type parameters. "If a specification expression includes a reference to an inquiry function for a type parameter or an array bound of an entity specified in the same , the type parameter or array bound shall be specified in a prior specification of the . The prior specification may be to the left of the inquiry function reference in the same statement. If a specification expression includes a reference to the value of an element of an array specified in the same , the array shall be completely specified in prior declarations." or F03/7.1.6 [126:9-14] "A variable in a specification expression shall have its type and type parameters, if any, specified by a previous declaration in the same scoping unit, by the implicit typing rules in effect for the scoping unit, or by host or use association. If a variable in a specification expression is typed by the implicit typing rules, its appearance in any subsequent type declaration statement shall confirm the implied type and type parameters. "If a specification expression includes a specification inquiry that depends on a type parameter or an array bound of an entity specified in the same , the type parameter or array bound shall be specified in a prior specification of the . The prior specification may be to the left of the specification inquiry in the same statement, but shall not be within the same . If a specification expression includes a reference to the value of an element of an array specified in the same , the array shall be completely specified in prior declarations." or F08/7.1.11p8+9 [10-007r1:151:3-12] "A variable in a specification expression shall have its type and type parameters, if any, specified by a previous declaration in the same scoping unit, by the implicit typing rules in effect for the scoping unit, or by host or use association. If a variable in a specification expression is typed by the implicit typing rules, its appearance in any subsequent type declaration statement shall confirm the implied type and type parameters. "If a specification expression includes a specification inquiry that depends on a type parameter or an array bound of an entity specified in the same , the type parameter or array bound shall be specified in a prior specification of the . The prior specification may be to the left of the specification inquiry in the same statement, but shall not be within the same . If a specification expression includes a reference to the value of an element of an array specified in the same , the array shall be completely specified in prior declarations." The rules regarding references to variables in specification expressions and initialization expressions require a strict left-to-right, top-to-bottom ordering between specification and inquiry. Specification functions appear to be unrestricted in this respect. Interp F95/0030 added the following new paragraph immediately before F03/Note 7.11 [04-007:127:33+] If an initialization expression in a module includes a reference to a generic, that generic shall have no specific procedures defined in the module subsequent to the initialization expression. And the following new paragraph immediately before F03/Note 7.10 [04-007:126:19+]: If a specification expression in a module includes a reference to a generic, that generic shall have no specific procedures defined in the module subsequent to the specification expression. QUESTION: The new paragraphs introduced into F03 by F95/0030, at [04-007:127:33+] and [04-007:126:19+], were changed in F08. The additional caveat "or submodule" was harmlessly introduced in four places by TR 19767. Paper 07-190r3 introduced "the of" in F08/7.1.12p3 [10-007r1:152:26-28] If a constant expression in the of a module or submodule includes a reference to a generic entity, that generic entity shall have no specific procedures defined in the module or submodule subsequent to the constant expression. and F08/7.1.11p9 [10-007r1:151:13-15] If a specification expression in the of a module or submodule includes a reference to a generic entity, that generic entity shall have no specific procedures defined in the module or submodule subsequent to the specification expression. Because of the changes introduced in F08 by 07-190r3, the paragraphs no longer address the question of interpretation request F95/0030, resulting in the example in the F95/0030 being standard conforming, contrary to the ANSWER to F95/0030. In light of F08 allowing generic interfaces to have specific procedures that are internal procedures, the following example illustrates a deeper problem than was illustrated in F95/0030: SUBROUTINE SUB INTERFACE INT PROCEDURE F1, F2 END INTERFACE CONTAINS INTEGER PURE FUNCTION F1(I) INTEGER :: A(INT(1_4)), B(INT(1_2)) ! A(1), B(19) INTEGER, PARAMETER :: KIND = SIZE(A) ! KIND == 1 INTEGER(KIND), INTENT(IN) :: I F1 = 17 END FUNCTION F1 INTEGER PURE FUNCTION F2(J) INTEGER :: C(INT(2_4)) ! C(2) INTEGER, PARAMETER :: KIND = SIZE(C) ! KIND == 2 INTEGER(KIND), INTENT(IN) :: J F2 = 19 END FUNCTION F2 END SUBROUTINE SUB Assuming that the processor supports integers with kind type parameters of 1, 2 and 4, was it the intent of the committee that this program unit example should be standard-conforming? ANSWER: No, it is clear from the answer to interpretation request F95/0030 that it is not the intent that the above program unit be standard conforming. The required complexity of implementation is not justified. The standard (as amended by corrigenda) briefly had prohibitions against it, but they were inadvertently removed during development of Fortran 2008. The edits below correct this. EDITS to 10-007r1: Replace F08/7.1.11p9 [10-007r1:151:13-15] by "A generic entity referenced in a specification expression in the of a scoping unit shall have no specific procedures defined in that scoping unit, or its host scoping unit, subsequent to the specification expression." Replace F08/7.1.12p3 [10-007r1:152:26-28] by "A generic entity referenced in a constant expression in the of a scoping unit shall have no specific procedures defined in that scoping unit, or its host scoping unit, subsequent to the constant expression." SUBMITTED BY: Van Snyder HISTORY: 11-101 m194 F08/0050 submitted - revision of F95/0030 11-101r1 m194 Passed by J3 meeting 11-xxx m195 Processed by J3 letter ballot #23 11-156 ---------------------------------------------------------------------- NUMBER: F08/0051 TITLE: Pure procedure arguments with VALUE KEYWORDS: INTENT, PURE, VALUE DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider PURE FUNCTION F(X) REAL,VALUE :: X F = X**2 END FUNCTION This subprogram does not conform to the Fortran 2003 standard, but appears to conform to the Fortran 2008 standard, as constraints C1276 and C1277 (in Fortran 2008) have been modified to remove the previous requirement for an INTENT specification in the case of arguments that have the VALUE attribute. However, this is not mentioned as a change in the Introduction. Was this change inadvertent? ANSWER: No, this change was deliberate. An edit is provided to clarify. EDITS tp 10-007r1: [xvi] Introduction, paragraph 2, last bullet point: Before "An impure" Insert the new sentence "An argument to a pure procedure may have default INTENT if it has the VALUE attribute.". SUBMITTED BY: Malcolm Cohen HISTORY: 11-139 m194 F08/0051 submitted - passed by J3 meeting 11-xxx m195 Passed as amended by J3 letter ballot #23 11-156 ---------------------------------------------------------------------- NUMBER: F08/0052 TITLE: Private type-bound procedures. KEYWORDS: Type extension, type-bound procedures, accessibility. DEFECT TYPE: Erratum. STATUS: Passed by J3 meeting QUESTION: Consider the program MODULE example1_m1 TYPE t1 CONTAINS PROCEDURE,PRIVATE,NOPASS :: p ! (1). END TYPE CONTAINS SUBROUTINE p PRINT *,'p' END SUBROUTINE SUBROUTINE do_p(x) CLASS(t1) x CALL x%p END SUBROUTINE END MODULE MODULE example1_m2 USE example1_m1 TYPE,EXTENDS(t1) :: t2 CONTAINS PROCEDURE,NOPASS :: p => p2 ! (2). END TYPE CONTAINS SUBROUTINE p2(n) PRINT *,'p2',n END SUBROUTINE END MODULE PROGRAM example1 USE example1_m2 TYPE(t2),TARGET :: x CLASS(t1),POINTER :: y y => x CALL do_p(x) ! (3): I expect this to print 'p'. CALL do_p(y) ! (4): I expect this to print 'p'. CALL x%p(13) ! (5): I expect this to print 'p2 13'. END PROGRAM Question 1: does type-bound procedure overriding take account of accessibility; that is, is the type-bound procedure statement at (2) (a) a valid new type-bound procedure definition, or (b) an invalid overriding of the definition at (1)? Question 2: If the answer to question 1 was "yes" (a), and the example is standard-conforming, are the expectations at (3), (4), and (5) correct? For the next question, consider the following program fragment: MODULE example2_m1 TYPE,ABSTRACT :: t1 CONTAINS PROCEDURE(p),PRIVATE,DEFERRED,NOPASS :: hidden ! (6). END TYPE CONTAINS SUBROUTINE p PRINT *,'p' END SUBROUTINE END MODULE MODULE example2_m2 USE example2_m1 TYPE,EXTENDS(t1) :: t2 CONTAINS PROCEDURE,NOPASS :: hidden => exposed ! (7). END TYPE CONTAINS SUBROUTINE exposed PRINT *,'exposed' END SUBROUTINE END MODULE Question 3: If the answer to question 1 was "yes" (a), then the definition of type t2 would seem to be defective in that (7) must be defining a new type-bound procedure, and not overriding the type-bound procedure defined at (6), and that therefore t2 still has a deferred type-bound procedure. That would mean that an abstract type with a private deferred type-bound procedure could not be extended outside of the module in which it is defined: is that correct? ANSWER: Q1. Yes, type-bound procedure overriding does take account of accessibility. This means that the type-bound procedure statement at (2) is (a) a valid new type-bound procedure definition. Subclause 4.5.7.3p1 says [78:4-6] "If a specific type-bound procedure specified in a type definition has the same binding name as a type-bound procedure from the parent type then [it] overrides the [inherited one]." If the inherited type-bound procedure is private, and the extending type definition is not in the same module, then the inherited type-bound procedure is not accessible by that name, so the condition "has the same binding name" cannot be satisfied. An edit is suggested for a future revision to make this wording clearer. Q2. Yes, the comments at (3), (4), and (5) are accurate. Q3. Yes, an abstract type with a private deferred type-bound procedure cannot be extended outside the defining module, because it is otherwise impossible to override the private type-bound procedure. EDITS to 10-007r1: [78:4] In 4.5.7.3p1, change "as a type-bound" to "as an accessible type-bound". SUBMITTED BY: Malcolm Cohen HISTORY: 11-141 m194 F08/0052 submitted - passed by J3 meeting 11-xxx m195 Processed by J3 letter ballot #23 11-156 ---------------------------------------------------------------------- NUMBER: F08/0053 TITLE: Restrictions on generic declarations, generic resolution KEYWORDS: generic declarations, generic resolution DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot BACKGROUND: There is a specification in 12.4.3.4 [283] of the properties that cause two dummy arguments to be distinguishable. C1214 [286] specifies that two procedures within the scope of a shall be distinguishable. There is no specification of the properties that cause two procedures to be distinguishable. 12.4.3.4.5p5 [286:38] specifies that a "generic invocation applies to...." QUESTIONS: (1) Shouldn't the requirement in C1214 be that the \cf{dtv} arguments are distinguishable? (2) Shouldn't 12.4.3.4.5p5 specify that a "generic nvocation is consistent with...?" ANSWERS: (1) Yes. (2) Yes. Edits are provided to clarify these two issues. EDITS to 10-007r1: [286:12-13 C1214] Editor: Replace "two ... identifier" by "if two procedures have the same generic identifier, their \cf{dtv} arguments". Insert "(9.6.4.8.3)" somewhere (your choice). [286:38 12.4.3.4.5p5] Editor: Replace "applies to" by "is consistent with". SUBMITTED BY: Van Snyder HISTORY: 11-136r2 m194 Submitted F08/0053 in section 2 11-136r1 m194 Passed section 1 - Editorial edits 11-136r3 m194 Section 2 passed by J3 meeting 11-xxx m195 Passed as amended by J3 letter ballot #23 11-156 ---------------------------------------------------------------------- NUMBER: F08/0054 TITLE: Requirements for needing an explicit interface KEYWORDS: Explicit interface DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the program SUBROUTINE Fred() BIND(C,NAME='Nurke') PRINT *,'ok' END SUBROUTINE SUBROUTINE S(dummy) INTERFACE SUBROUTINE dummy() BIND(C) END SUBROUTINE END INTERFACE CALL dummy END SUBROUTINE PROGRAM example1 EXTERNAL Fred,S CALL S(Fred) END PROGRAM According to 12.4.2.2, an explicit interface is only ever required in a scope where a procedure is referenced. The main program does not reference Fred, so this appears to be conforming. It appears that no processors accept this example... However, the very similar program minus the BIND(C) specifications SUBROUTINE Freddy(x) LOGICAL,OPTIONAL :: x IF (PRESENT(x)) PRINT *,'ok' END SUBROUTINE SUBROUTINE SUB(dummy) INTERFACE SUBROUTINE dummy(x) LOGICAL,OPTIONAL :: x END SUBROUTINE END INTERFACE CALL dummy(.TRUE.) END SUBROUTINE PROGRAM example2 EXTERNAL Freddy,SUB CALL SUB(Freddy) END PROGRAM but with a different reason for requiring an explicit interface, is also apparently valid in Fortran 2003/2008 but is not valid in Fortran 90 or Fortran 95, because they require the explicit interface without the condition of the procedure being referenced in that scope. This feature (viz only require the explicit interface where it is referenced) was added by paper 02-144, which makes no mention of it being a new feature. Was this a deliberate new feature? ANSWER: No, this was a mistake in 02-144 and thus in Fortran 2003 and 2008. An edit is provided to correct the mistake. EDITS to 10-007r1: In 12.4.2.2p1 [279:19], delete "it is referenced and". SUBMITTED BY: Malcolm Cohen HISTORY: 11-135 m194 F08/0054 submitted 11-135r1 m194 Passed by J3 meeting 11-xxx m195 Passed as amended by J3 letter ballot #23 11-156 ----------------------------------------------------------------------