13-237 To: J3 Members From: Stan Whitlock Subject: Results of the J3 Fortran interp letter ballot #27 Date: 2013 February 08 Here are the results of J3 letter ballot #27 on Fortran interpretations that officially closed 11-Jan-2013. The ballot is in J3 paper 13-203 for meeting #200. If I have transcribed a vote or a comment incorrectly, please let me know. J3 rep F03 F08 F08 F08 F08 F08 053 075 083 084 085 086 result of #27 C Y Y Y N N Dan Chen Y Y Y Y Y N Malcolm Cohen Y C Y Y Y N Robert Corbett Y C Y Y Y N Bill Long Y Y Y Y C C Toon Moene Y Y Y Y Y N Dan Nagle Y Y Y Y Y Y John Reid Y Y Y Y Y N Van Snyder C Y Y Y C Y Stan Whitlock Y Y Y Y Y Y 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 comments for each interp are separated by a line of "*"s. The interps marked "C" pass with some minor fixes, as noted below. The interps marked "N" fail. The edited interps in their final form are attached and will appear in the next version 006A. /Stan ************************************************************************ F03/0053 The BIND attribute for C_PTR and C_FUNPTR Van Snyder's Yes with Comment vote on F03/0053: Trivial typo in the description for the [431:6] edit: "replacce" -> "replace" Result for F03/0053: accept Van's fix; passed as amended ************************************************************************ F08/0075 Pointer function reference as variable in assignment Malcolm Cohen's Yes with Comment vote on F08/0075: This interp as about the syntactic problems caused by F2008's operator syntax for "pointer function reference as variable". It is not about the latter changing the semantics of F2003 programs with SELECT TYPE or ASSOCIATE. I agree with Robert Corbett that on the face of it there is an apparent problem, but this needs to be dealt with separately. As the standard is in F2008 as published and as would be after applying the edits in F08/0075, his example is technically not conforming as the semantics from clause 8 contradict the "upwards compatible" statement in clause 1. That's not a particularly reasonable outcome! But is not related to whether we can use operator syntax to denote a variable. Robert Corbett's Yes with Comment vote on F08/0075: As I pointed out in e-mail on 2012 May 18 and at meeting #199, changing the boundary between expressions and variables changes the semantics of the ASSOCIATE and SELECT TYPE constructs. The proposed edits result in semantics that are different from the semantics of both Fortran 2003 and Fortran 2008 as published. Text should be added to Clause 1.6.2 noting the semantic difference between Fortran 2003 and the edited version of Fortran 2008. The answer should make note of the difference between the original version of Fortran 2008 and the edited version of Fortran 2008. The example I gave in my e-mail was FUNCTION F(P) POINTER F, P F => P END PROGRAM ASSOC TARGET X POINTER P INTERFACE FUNCTION F(P) POINTER F, P END FUNCTION END INTERFACE X = 1.0 P => X ASSOCIATE(Y => F(P)) X = 2.0 PRINT *, X, Y END ASSOCIATE END In Fortran 2003, the selector in the ASSOCIATE statement is not a variable. Therefore, the associate name Y is associated with the value of the expression F(P), not with the data object named by X (see 16.5.1.6, paragraph 4 [446: 13-15] of the Fortran 2008 standard or 16.4.1.5, paragraph 4 [413: 13-15 of the Fortran 2003 standard). Therefore, the assignment to X in the ASSOCIATE construct does not change the value of Y, and so the program prints " 2.0 1.0". In Fortran 2008, with or without the edit, the selector is a variable. Therefore, Y is associated with the data object named by X. The assignment to X changes the value of the data object with which Y is associated, and so the program prints " 2.0 2.0". Result for F03/0075: Passed Meeting #200, paper 13-228r1 introduces a new interp, F08/0089, "Variable-denoting functions change existing semantics", that addresses Bob's complaint. ************************************************************************ F08/0085 Problems with PARAMETERs Bill Long's Yes with Comment vote on F08/0085: The new C507a at [88:14+] says "A that specifies a type parameter ... shall be a constant expression." A KIND type parameter already has to be a constant expression, so a bit of restatement here. Should we insert "length" before "type parameter" in the constraint? This focuses on the actual issue and is more similar to the "array bound" that comes later. Van Snyder's Yes with Comment vote on F08/0085: Trivial typo in the first question: Insert "see" after "we" in the second line after the example. Result for F08/0085: Failed LB #27 * accept Van's fix * On re-examination of the syntax rules we have discovered that type parameter values are not specified by s in any case – R401 used , so the edit to [88:14] is broken anyway. Bill is right that C401 means that the new constraint does not have to mention kind type parameters. * So we recommend changing “A that specifies a type parameter” to “An expression that specifies a length type parameter”. It is safer to fail this answer so it gets another round of being-looked-at, since no-one picked this up the first time. ************************************************************************ F08/0086 Implied-shape and separate PARAMETER statement Daniel Chen's No vote on F08/0086: Agree with Bob's comment on Q2. Malcolm Cohen's No vote on F08/0086: I agree with Bill Long's comment that the new constraint should replace the old constraint. I agree with Robert Corbett's comment that the second example needs to have its unrelated errors removed. I agree that there is a difficulty with incorrect rank, but disagree that that is related to this interp in any way, especially as the purported problems are not limited to implied-shape arrays. I disagree with the comment that ambiguous syntax is just fine and dandy. Programs that use ambiguous syntax are not conforming; having ambiguous syntax in the standard just makes it less obvious that non-conforming programs are not conforming. If we want to add an array-spec, let's add it, not just pretend that it's there when it is not. Otherwise someone is quite likely not to implement this imaginary extension. Robert Corbett's No vote on F08/0086: The questions as given contain errors. The brief answers given do not make clear what aspect of the questions they are answering. Consider the code given in question Q2. Almost anyone with a nodding familiarity with Fortran would understand that the program does not conform to the Fortran standard because b is declared to be both Real and Integer. Ignoring the conflicting type declarations, the declarations of b and c are still troubling. Both b and c are declared to be rank one arrays (see 5.3.8.6, paragraph 2 [96: 28]). The bounds and extents of a rank one array cannot be the same as those of a scalar . I did not find a statement in the Fortran 2008 standard that requires the that specifies the value of an implied-shape named constant to have the same rank as the named constant, but there should be one. The requirement should be a constraint. The Fortran standards from Fortran 90 through Fortran 2008 have allowed a single to denote more than one class of array. Consider the subroutine SUBROUTINE SUBR(A, P) REAL, DIMENSION(:) :: A, P, Q POINTER P, Q END The in DIMENSION(:) is an for A and a for P and Q. The syntax is ambiguous, but the meaning is clear from context. I see no reason to treat assumed-size and implied-shape arrays differently. Adding the requirement that an implied-shape array can appear only in a type declaration statement that specifies the PARAMETER attribute introduces an unnecessary inconsistency to the language. I have often seen code such as INTEGER A(3) PARAMETER (A = (/ 1.0, 2.0, 3.0 /) ) I think people would be confused to find that rewriting the code as INTEGER A(*) PARAMETER (A = (/ 1.0, 2.0, 3.0 /) ) is not allowed. Bill Long's Yes with Comment vote on F08/0086: The new C535a says that the can only appear in a declaration with the PARAMETER keyword. That automatically makes the thing being declared a named constant. Does this make the existing C535 redundant? Should we just replace C535 with the new constraint? Toon Moene's No vote on F08/0086: Agree with Bob - this interp (second example) needs to be rethought. John Reid's No vote on F08/0086: It is clear from the votes of others that more work is needed on this. Result for F08/0086: Failed LB #27 We can fix Q2 before failing it: 2nd line of example, change “a,b,c” => “a,c” delete 3rd line “Integer,Parameter :: b = 123” 4th line “45.6” => “[ 45.6 ]” 5th line, “a(b)” => “a(123)”. Meeting 200 paper 13-229, F08/0090, "What restrictions apply to initialization and PARAMETER?", introduces a new interp that addresses the concern “an implied-shape named constant [should] have the same rank as the named constant”. Meeting 200 paper 13-235 amends F08/0086 for a straw vote as to whether to allow implied-shape to work with PARAMETER properly as per BobC’s comment. ------------------------------------------------------------------------ NUMBER: F03/0053 TITLE: The BIND attribute for C_PTR and C_FUNPTR KEYWORDS: BIND attribute, C_PTR, C_FUNPTR, private components DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: 1. Do the derived types C_PTR and C_FUNPTR have the BIND attribute? This affects whether an object of one of these types is permitted directly in COMMON. C5101 in the Fortran 2008 standard states "If a common-block-object is of a derived type, it shall be a sequence type or a type with the BIND attribute and it shall have no default initialization." 2. Whether the derived types C_PTR and C_FUNPTR have the BIND attribute affects whether they are extensible. Subclause 4.5.7.1 of the Fortran 2008 standard states "A nonsequence derived type that does not have the BIND attribute is an extensible type." Are these types extensible? 3. Subclause 15.3.3 of the Fortran 2008 standard states that C_PTR and C_FUNPTR are derived types with private components. Are user-defined derived types with the BIND attribute permitted to have private components? ANSWER: 1. No, these types do not have the BIND attribute. 15.3.3 does not specify that they have the BIND attribute. 15.3.4 does not require them to have the BIND attribute in order to make them interoperable. 15.3.5 would require them to interoperate with a C struct if they had the BIND attribute; this is absurd, since C object pointers and C function pointers are clearly not structs. Note that whether these types have default initialization is not specified by the standard, so possession of BIND would not necessarily have allowed them in COMMON anyway. Edits are provided to correct incomplete, and thus misleading, statements about derived types and the BIND attribute. 2. No, these types were not intended to be extensible. It was an oversight that these types were not explicitly excluded from being extensible by subclause 4.5.7.1 paragraph 1 of the Fortran 2008 standard. An edit is provided to correct this. 3. Yes, a user-defined derived type with the BIND attribute is permitted to have private components. This situation is the same as for SEQUENCE types, which are similar (but not interoperable). As with SEQUENCE types, making a component PRIVATE does prevent access, in a conforming program, to the component by a programmer who is sufficiently determined; however, it continues to fulfill the software engineering role for which it was intended. Note further that there are many other situations where two different Fortran derived types will interoperate with the same C derived type; this is not a defect in either standard, but simply a consequence of the two languages having different approaches to type compatibility. EDITS to 10-007r1: [19:15-16] In 1.3.147.6, replace the definition of "extensible type" with "type that may be extended using the EXTENDS clause (4.5.7.1)". {Repair definition of extensible type.} [77:3] In 4.5.7.1p1, After "A derived type" insert ", other than the type C_PTR or C_FUNPTR from the intrinsic module ISO_C_BINDING," {Prohibit these types from subsequent extension.} [431:6] In 15.3.4p1, replace entire paragraph with "Interoperability between derived types in Fortran and struct types in C is provided by the BIND attribute on the Fortran type." {Reduce misleading opening blather - this is just here so we didn't start the subclause with a bunch of constraints. Alternatively we could move paragraph 2 (and note 15.12) to replace paragraph 1.} [431:12+2] In 15.3.4, Note 15.11, After "is interoperable" insert "with a C struct type". {Correct another misleading sentence.} [431:13-18] In 15.3.4p2, Change all four occurrences of "Fortran derived type" to "derived type"; change the single occurrence of "Fortran type" to "derived type". {Remove unnecessary and confusing qualification of "derived type" with "Fortran".} SUBMITTED BY: John Reid HISTORY: 05-151 m171 F03/0053 submitted - Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 N1622 m172 Failed WG5 ballot N1629 11-217r1 m195 Revised answer for Fortran 2008 - Passed by J3 meeting 11-241 m196 Passed as amended by J3 letter ballot #24 11-229 12-165r2 m198 Passed by J3 letter ballot #25 12-147 12-193 m199 Failed WG5 ballot #3 N1932/N1933/N1939 12-190 m199 Revised answer/edits - passed by J3 meeting 13-xxx m200 Passed as amended by J3 letter ballot #27 13-203 ---------------------------------------------------------------------- NUMBER: F08/0075 TITLE: Pointer function reference as variable in assignment KEYWORDS: Pointer function, assignment, defined operator DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: (1) Consider the following module Funcs interface operator ( .op. ) module procedure Unary, Binary end interface contains function Unary ( Arg ) integer, intent(in) :: Arg integer, pointer :: Unary ... end function Unary function Binary ( Arg1, Arg2 ) integer, intent(in) :: Arg1, Arg2 integer, pointer :: Binary ... end function Binary end module Funcs program What use Funcs integer :: X, Y = 42 10 .op. x = y end program What Is the "10" in "10 .op. x = y" an operand, and therefore an argument of a reference to Binary, or is .op. a reference to Unary and "10" a statement label? (2) Consider the following module Funcs interface operator ( .op. ) module procedure Unary, Binary end interface contains function Unary ( Arg ) integer, intent(in) :: Arg character(len=...), pointer :: Unary ... end function Unary function Binary ( Arg1, Arg2 ) integer, intent(in) :: Arg1, Arg2 character(len=...), pointer :: Binary ... end function Binary end module Funcs program What use Funcs integer :: X = 42, Y read (10) .op. x, y end program What Is "10" an , or is "(10) .op. x" a ? Note that this program is valid Fortran 90, and "(10) .op. x" is a according to the Fortran 90 standard. ANSWER: It was an oversight that the programs in (1) and (2) conform to the syntax and constraints in two different ways. The problem stems from the over-ambitious extension of allowing pointer function references to denote variables; this was unambiguous for syntax, but is not for operator syntax. Also, operator syntax has other restrictions on it that are intended to prevent modification of an operand, and these are subverted if the result is treated as a variable. Edits are supplied to remove the treatment of pointer-valued operators as variables. EDITS: [117:13] In 6.2, R602, change "" to "". [117:15] In 6.2, C602, change " ... has" to " shall have". [158:18+] In 7.2.2.2, R737, add new production "<> ". {Restore description of to F2003 version.} [158:20+] In 7.2.2.2, After C724, add new constraint "C724a (R737) An shall be a reference to a function that has a data pointer result." {Restore F2003 constraint (more or less).} SUBMITTED BY: Van Snyder HISTORY: 12-149 m198 F08/0075 submitted 12-149r1 m198 Revised edit 12-149r2 m198 Clarified answer, passed J3 meeting 12-196 m199 Subsumed F08/0076 and Failed J3 letter ballot #26, 12-184 12-197 m199 Revised answer/edits - passed by J3 meeting 13-xxx m200 Passed by J3 letter ballot #27 13-203 ---------------------------------------------------------------------- NUMBER: F08/0083 TITLE: Type parameter default expressions allow circular dependence KEYWORDS: type parameter expressions, circular dependence DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider type :: T ( I, J ) integer, kind :: I = J + 1 integer, kind :: J = I + 1 end type T type(t) :: X(1,2) print *, x%i, x%j end 1. Is the program standard conforming? 2. What does it print? ANSWER: 1. The program is not conformant because the standard does not establish an interpretation. An edit is supplied to make it clear that the program is not comformant. 2. The standard does not establish an interpretation. EDITS: Replace item (9) in the list in 7.1.12p1 [12-007:152:9]: (9) "a previously declared kind type parameter of the type being defined," SUBMITTED BY: Van Snyder HISTORY: 12-172 m199 F08/0083 submitted - passed by J3 meeting 13-xxx m200 Passed by J3 letter ballot #27 13-203 ---------------------------------------------------------------------- NUMBER: F08/0084 TITLE: Pointer arguments to PURE functions KEYWORDS: PURE function, POINTER, INTENT(IN) DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the following subprogram: Real Pure Function F( X ) Real,Pointer :: X Real :: F f = 1.0 x = 2.0 ! (A) Nullify(x) ! (B) End Function F This subprogram does not conform to Fortran 2003, because both statements (A) and (B) violate constraint C1272 which says "C1272 In a pure subprogram any designator with a base object that ... is a dummy argument of a pure function ... shall not be used ... [in] a variable definition context ...". However, the corresponding constraint in Fortran 2008, C1283, is missing the condition that applies the constraint to a dummy argument of a pure function, except when it has INTENT(IN). Thus the statements marked (A) and (B) do not violate C1283, and therefore this subprogram appears to conform to Fortran 2008. Was this subprogram intended to be standard-conforming? ANSWER: No, this subprogram was not intended to be standard-conforming. An edit is supplied to re-insert the omitted condition. EDIT to 10-007r1: [312:31] In 12.7, constraint C1283, after "association", insert ", is a dummy argument of a pure function". SUBMITTED BY: Tobias Burnus HISTORY: 12-174 m199 F08/0084 submitted 12-174r1 m199 Revised 12-174r2 m199 Passed by J3 meeting 13-xxx m200 Passed by J3 letter ballot #27 13-203 ---------------------------------------------------------------------- NUMBER: F08/0085 TITLE: Problems with PARAMETERs KEYWORDS: PARAMETER DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: (1) Consider the program fragment Subroutine s Parameter (n=1) Integer :: x,n !(A) Parameter (x=3) The type declaration statement marked "!(A)", declares the entities X and N to be of type INTEGER. Furthermore, as we see by the immediately preceding and following PARAMETER statements, both X and N are named constants. Unfortunately, a constraint says C507 (R503) "An shall appear if the entity is a named constant (5.3.13)." (BTW, R503 is .) Therefore one concludes that the type declaration statement marked "!(A)" is not conforming as it violates C507 for both X and N. Is this statement intended to be conforming? (2) Firstly, consider Subroutine s2(n) Integer,Parameter :: x(n:n+1) = [ 1,2 ] Character(n),Parameter :: y = 'abc' ... The type declaration statements are not conforming because according to 5.2.2p1, X and Y are automatic data objects, and C506 says that shall not appear in that case. Now consider Subroutine s2b(n) Implicit Character(n) (a-z) Parameter (y = 'abc') Integer :: x(n:n+1) Parameter(x=[1,2]) This is not valid Fortran 2003, because 5.2 contains the requirement: "The combination of attributes that may be specified for a particular entity is subject to the same restrictions as for type declaration statements regardless of the method of specification. This also applies to PROCEDURE, EXTERNAL, and INTRINSIC statements." This requirement does not appear in F2008. However, there is no indication in the Introduction of this new feature. Is this extension to Fortran 2003 deliberate? ANSWER: (1) Yes, the type declaration statement was intended to be allowed. An edit is supplied to correct this mistake. (2) No, the omission of this requirement was inadvertent. An edit is supplied to correct this mistake. EDITS: [88:14] In 5.2.1, Replace constraint "C507 (503)" completely with "C507 (R501) If the PARAMETER keyword appears, shall appear in each ." {Fix Q1.} [88:14+] In 5.2.1, immediately after constraint C507, insert new constraint: "C507a A that specifies a type parameter or array bound of a named constant shall be a constant expression." {Fix Q2.} SUBMITTED BY: Malcolm Cohen HISTORY: 12-189 m199 F08/0085 submitted 12-189r1 m199 Passed by J3 meeting 13-xxx m200 Failed as amended by J3 letter ballot #27 13-203 Result for F08/0085: Failed LB #27 * accept Van's fix * On re-examination of the syntax rules we have discovered that type parameter values are not specified by s in any case – R401 used , so the edit to [88:14] is broken anyway. Bill is right that C401 means that the new constraint does not have to mention kind type parameters. * So we recommend changing “A that specifies a type parameter” to “An expression that specifies a length type parameter”. It is safer to fail this answer so it gets another round of being-looked-at, since no-one picked this up the first time. ---------------------------------------------------------------------- NUMBER: F08/0086 TITLE: Implied-shape and separate PARAMETER statement KEYWORDS: Implied-shape, PARAMETER DEFECT TYPE: Clarification or Erratum STATUS: J3 consideration in progress QUESTION: Q1. Consider Program test1 Character(*) a,b(*) Dimension c(*) Parameter (a='123', b=['1','2','3']) Character(*),Parameter :: c = [ '44','55','66' ] Print *,a,b,c End The definition of the assumed-length character named constant A conforms to Fortran 77 to Fortran 2008. However, the definition of the implied-shape named constant B appears not to conform to Fortran 2008, as the standard says in 5.4.11p2 "A named array constant defined by a PARAMETER statement shall have its shape specified in a prior specification statement." On the other hand, the named constant C does not have such a requirement, so its definition would appear to be conforming. This apparent requirement on the named constant B would thus appear to be inconsistent with those on the named constant C, as well as inconsistent with the way that assumed length works, and with the general principle of allowing attributes to be specified either in a single type declaration statement or with separate specification statements. Is the program intended to conform to the Fortran standard? Q2. Consider Subroutine test2(a) Real,Dimension(*) :: a,c Parameter (c = [ 45.6 ] ) a(123) = c End Subroutine The in the type declaration statement is ambiguous; if it is an then the declaration of A as an assumed-size array is erroneous, but if it is an then the declarations of B and C as implied-shape arrays is erroneous. Is this program-unit intended to be standard-conforming? ANSWER: A1. No, the program is not intended to conform to the Fortran standard. A clarifying edit is supplied to make it clear that an implied-shape array specification is only permitted for a named constant whose value is given in the same statement. This makes it clear that the declarations of both B and C are non-conforming. A2. No, the program is not intended to conform to the Fortran standard. This is clarified by the same edit that clarifies the answer to question 1. EDIT to 10-007r1: [97:27+] In 5.3.8.6, insert new constraint "C535a An shall appear only in a type declaration statement in which the PARAMETER keyword appears." SUBMITTED BY: Bill Long HISTORY: 12-191 m199 F08/0086 submitted - revised by Malcolm Cohen - passed by J3 meeting 13-xxx m200 Failed as amended by J3 letter ballot #27 13-203 Result for F08/0086: Failed LB #27 We can fix Q2 before failing it: 2nd line of example, change “a,b,c” => “a,c” delete 3rd line “Integer,Parameter :: b = 123” 4th line “45.6” => “[ 45.6 ]” 5th line, “a(b)” => “a(123)”. Meeting 200 paper 13-229, F08/0090, "What restrictions apply to initialization and PARAMETER?", introduces a new interp that addresses the concern “an implied-shape named constant [should] have the same rank as the named constant”. Meeting 200 paper 13-235 amends F08/0086 for a straw vote as to whether to allow implied-shape to work with PARAMETER properly as per BobC’s comment. ----------------------------------------------------------------------