12-196 To: J3 From: Stan Whitlock/Malcolm Cohen Subject: Results of the J3 interp letter ballot #26 Date: 2012 Oct 18 Here are the results of J3 letter ballot #26 on Fortran interpretations that officially closed 12-Oct-2012. The ballot is in J3 paper 12-184 for meeting #199. If I have transcribed a vote or a comment incorrectly, please let me know. J3 rep F08 F08 F08 F08 F08 F08 F08 F08 F08 F08 040 074 075 076 077 078 079 080 081 082 result of #26 C Y N S Y Y C C C C Dan Chen Y Y N N Y Y C Y Y Y Malcolm Cohen Y Y N N Y Y Y Y Y Y Robert Corbett C Y N N C N N Y N N Bill Long C Y C Y Y Y C C Y C Toon Moene Y Y N N Y Y Y Y Y Y Dan Nagle Y Y Y Y Y Y Y Y Y Y John Reid C Y N N Y Y Y Y C Y Van Snyder Y C C Y N Y Y C C C Stan Whitlock Y Y Y Y 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 interp marked "S" is subsumed by another interp. The edited interps in their final form are attached and will appear in the next version 006A. /Stan ************************************************************************ F08/0040 MOVE_ALLOC for coarrays Bob Corbett's Yes with Comment vote on F08/0040: The answer says "the coranks of FROM and TO need to be the same." The discussion says "the dummy arguments of MOVE_ALLOC do not technically have corank." I think I understand how both statements can be true, but it did confuse me at first. I suggest eliding the statement from the discussion. Bill Long's Yes with Comment vote on F08/0040: In the first edit, the edit instructions begin: [97:13] In 5.3.10 INTENT attribute, However, when the [page:line] is removed for the corrigendum, the subsequent instructions will be ambiguous since the section contains multiple instances of "entity". The other edits have instructions that are complete enough to omit the [page:line]. Seems better to do the same for the first one. Something like [97:13] In 5.3.10 INTENT attribute, constraint C541, John Reid's Yes with Comment vote on F08/0040: The edit for 5.3.10 should be [97:13] In 5.3.10 INTENT attribute, C541, Change "An entity" to "A dummy argument of a nonintrinsic procedure". Result: Accept John's and Bob's changes. F08/0040 passes as amended. ************************************************************************ F08/0074 Implicit type in BLOCK construct Van Snyder's Yes with Comment vote on F08/0074: In the question, in the first line after the sample program, remove "the" before "X", or insert "variable" before "X". Result: No edit is needed. "the x inside the BLOCK construct" in the existing edit uniquely identifies the x being asked about. F08/0074 passes with no changes. ************************************************************************ F08/0075 Pointer function reference as variable in assignment Daniel Chen's No vote on F08/0075 I agree with Malcolm. Bob Corbett's No vote on F08/0075: I am happy with the answer given, although I think the edit can be simplified. I am voting "no" because I think we should consider other possible solutions. I think the suggestion made by Rafik Zurob during meeting 198 deserves further consideration. He suggested requiring an used as a variable to be a function reference. That cannot be done in a blanket fashion without breaking compatibility with Fortran 2003. However, I think it can be done if exceptions are made for a few cases. Bill Long's Yes with Comment vote on F08/0075: The edit is faulty. I assume that "label" should follow the second "statement" in the Edit. So the edit ends "... that is not part of a statement label shall not be a digit." If this assumption is incorrect, then my vote is No, since I don't understand the current edit text. Minor: EDITS: -> EDIT: (since there is only one). Malcolm Cohen's No vote on F08/0075: (Note that the edit is wrong - missing 'label' after the second statement - but that is not the reason for voting NO.) Even though a '.ADDRESS.' operator might look 'cool', I have come to the conclusion that allowing operator syntax to denote variables is a mistake. The standard has various restrictions on operators to reduce the ability to obfuscate your code, e.g. arguments are required to be INTENT(IN). The purpose of operator syntax was to allow user-defined algebra, not junk coding. There is no functionality provided by this feature that is not adequately served, with less obfuscation, by function reference syntax. The correct fix for this interp is to acknowledge our mistake in permitting this syntax to occur at all anywhere, and changing R602 and C602 to R602 variable is designator or function-reference C602 (R602) function-reference shall have a data pointer result. Note that a less extreme viewpoint would be to allow the operator syntax except as the variable in an assignment statement (or READ statement). That would be a better solution than the nitpicky syntax tweaks that are the current proposed solutions to this interp and the next, but would not be as consistent as disallowing this problematic syntax entirely. Bob Corbett's comment on Malcolm's vote: Rafix Zurob's proposal in meeting 199 was similar to this proposal. The problem we identified then was that the change made in Fortran 2008 has been integrated into the standard in more than one place. For example, in Fortran 2003, the statement P => Q + 1 where the operation Q + 1 returns a pointer to a data object is permitted. If only the change suggested is made, that statement will not be permitted in Fortran 2008. There are decisions that will have to be made regarding the ASSOCIATE and SELECT TYPE statements. Malcolm's comment on Bob's comment: Robert Corbett writes: <<< Rafix Zurob's proposal in meeting 199 was similar to this proposal. The problem we identified then was that the change made in Fortran 2008 has been integrated into the standard in more than one place. For example, in Fortran 2003, the statement P => Q + 1 where the operation Q + 1 returns a pointer to a data object is permitted. If only the change suggested is made, >>> I think you mean 'the edit suggested'... as my suggested change was to remove the operator syntax for denoting variables that was added in F2008. In F2003, Q+1 does not denote a variable, in fact quite the opposite, it returns a 'pointer association'. This is not required to denote a variable! <<< that statement will not be permitted in Fortran 2008. >>> Right, it would be a mistake to introduce that incompatibility. I was not suggesting making that mistake. It looks to me like F2008 has another mistake here already, since Q+1 is permitted to return a null pointer, and this definitively does not denote any variable! I accept that my initial suggested edits are not complete. However, there are relatively few places in the language that count as 'pointer context', so it will not be onerous to check that these will all be ok (but I didn't do that before making my interp ballot comment). <<< There are decisions that will have to be made regarding the ASSOCIATE and SELECT TYPE statements. >>> There are decisions to be made full stop. I do not see any particular reason to treat associate selectors that are expressions differently from any other expressions though. Toon Moene's No vote on F08/0075: I agree with Malcolm's analysis why F08/0075 is wrong and couldn't possibly have worded it better. John Reid's No vote on F08/0075: I agree with Malcolm Van Snyder's Yes with Comment vote on F08/0075: Would benefit from a note explaining the mysterious requirement. Result: A new answer and edits need to be prepared => F08/0075 fails. ************************************************************************ F08/0076 Pointer function reference in READ Daniel Chen's No vote on F08/0075 I agree with Malcolm. Bob Corbett's No vote on F08/0076: My comments for F08/0075 also apply here. Malcolm Cohen's No vote on F08/0076: This should also be fixed by removing this particular syntax (operators) for the feature (pointer function reference as variable). Or at the very least, removing it from the READ statement. Toon Moene's No vote on F08/0076: I agree with Malcolm's analysis why F08/0076 is wrong and couldn't possibly have worded it better. John Reid's No vote on F08/0076: I agree with Malcolm Result: This is another instance of the same problem (syntactic ambiguity) caused by the same feature (operator syntax for variable denotation) as F08/0075, so needs to be answered together with F08/0075, => example will be added to F08/0075, and F08/0076 is therefore subsumed by F08/0075. ************************************************************************ F08/0077 Function references as variables in DATA statements Bob Corbett's Yes with Comment vote on F08/0077: Changes to the resolution of F08/0075 and F08/0076 might have an effect on the edits given here. Van Snyder's No vote on F08/0077: Since the only alternatives for are and , it seems weird to have in the syntax rule, and then a constraint that says it is required to be , not . If it works, I would prefer to change the first alternative of R536 at [104:15] from to , and then use instead of in C566 at [104:26] and C568 at [104:32]. A change would also be required in C567 at [104:28-29], to something like "A that appears ... shall not designate a variable that is a dummy argument...." If for some reason that doesn't work, I accept the proposed repair. Malcolm Cohen's comments on Van's comments: > Since the only alternatives for are > and , it seems weird to have in the syntax > rule, and then a constraint that says it is required to be > , not . ... > If for some reason that doesn't work, Obviously doesn't work because a is not necessarily a . Use of with Cxxx The shall be a . is not obviously worse than use of of with Cxxx The shall not be a constant or a subobject of a constant. > accept the proposed repair. I am somewhat boggled that this warrants voting NO with a comment that if your variation on the fix doesn't work (as it doesn't out of the box) then you vote YES (I presume that's what "accept the proposed repair" means). Surely more appropriate to vote "C" saying you prefer alternative fix, ne? Van's response to Malcolm: OK, I overlooked the necessity to duplicate C601. Instead of the proposed repair, an alternative is to add a syntax rule, instead of a constraint that says "you can only choose the first alternative for the syntax rule in this circumstance:" [6.2 117:12-14] R602 <> <> R602a <> C601 (R602a) shall not be a constant or a subobject of a constant and move C602 above R602a, since it continues to apply to R602. Then in R536 use instead of , and make the corresponding changes in the related constraints. Result: F08/0077 passes with no changes. ************************************************************************ F08/0078 Are the IEEE values +0 and -0 distinguished Bob Corbett's No vote on F08/0078: I disagree with the interpretation. I think that the distinction between +0 and -0 is such an important component of IEC 60559:1989 that it should be required if IEEE_SUPPORT_DATATYPE is true. Result: F08/0078 passes with no changes. ************************************************************************ F08/0079 NAMELIST and type specification Daniel Chen's No vote on F08/0079: There are typos in the example as Bill indicated. My vote should be changed to 'YES' after the typos are fixed. Bob Corbett's No vote on F08/0079: I agree with the point raised in question Q4 that it is unclear whether the requirement for confirmation is intended to apply to length type parameters. I think the problem is greater than that The interpretation given here assumes that the namelist group object is implicitly typed if the NAMELIST statement precedes an explicit declaration of its type. That assumption is contradicted by paragraph 4 of Clause 5.5 [109:17-19]. The declared type of a namelist group object will be established either by implicit or explicit typing. Therefore, the only portion of paragraph 5 of Clause 5.6 [111:19-23] that is required for types and type parameters is the second sentence. The first sentence is needed only for the rank. A possible rewrite of paragraph 5 of Clause 5.6 that resolves the problems is: If the rank of a namelist group object is specified by a specification statement in the same scoping unit as the NAMELIST statement, that specification statement shall precede the NAMELIST statement. If the type of a namelist group object is explicitly declared by a type declaration statement in the same scoping unit as the NAMELIST statement and the NAMELIST statement precedes the type declaration statement, the explicit type and its type parameters shall match the type and corresponding type parameters that the implicit mapping for the scoping unit would assign the name of the namelist group object. Bill Long's Yes with Comment vote on F08/0079: The test codes have numerous typos/syntax errors: in Q2: Class(t),Intent(In) :: dtv should be Class(t(6)),Intent(In) :: dtv - original was missing a required KIND type parameter value Allocate(x, Source=t(6)(1.5) ! B is missing a ")" after the (1.5). in Q3: Allocate(x, Source=t(6)(1.5) ! B is missing a ")" after the (1.5). in Q4: Class(t),Intent(In) :: dtv should be Class(t(*)),Intent(In) :: dtv - original was missing a required type parameter value Allocate(x,Source=t(1,[15])) ! B should be Allocate(x,Source=t(1)([15])) - original was missing the type parameter because of wrong syntax. Result: Accept Bill's typo fix-ups. F08/0079 passes as amended. ************************************************************************ F08/0080 Array constructors with polymorphic values Bill Long's Yes with Comment vote on F08/0080: The code example for Q2 declares and allocates the variable Z, but does nothing with it. Seems irrelevant to the Question asked. Van Snyder's Yes with Comment vote on F08/0080: Presumably, the penultimate line of Program m198_003a in Q2 ought to be "Print *, [ x, y, z ]". Otherwise, the question doesn't make sense. Maybe the program name ought to be m198_003b. Result: Accept Van's changes. F08/0080 passes as amended. ************************************************************************ F08/0081 Deallocation error handling Bob Corbett's No vote on F08/0081: I continue to believe that the 4.5.6.3 means and should mean that finalizers are invoked only after successful deallocations. The interpretation given is likely to lead to data structures left in indeterminate states. I think that will severely restrict what a program can safely do after an error condition occurs during deallocation. John Reid's Yes with comment vote on F08/0081: After the changes of corrigendum 1, the edit for 4.5.6.3 is to the second paragraph. Van Snyder's Yes with Comment vote on F08/0081: In the edits for [76:10] and [131:12], I would prefer "during" to "in". Result: Accept John and Van's changes. F08/0081 passes as amended. ************************************************************************ F08/0082 Generic identifier and dtv arguments Bob Corbett's No vote on F08/0082: There is a problem with the wording of the constraint. The definition of the term "generic identifier" is: 1.3.78 generic identifier lexical token that identifies a generic set of procedures, intrinsic operations, and/or intrinsic assignments. None of the alternatives for a (R1208) is a lexical token. Either the wording of the constraint needs to change or the definition of a generic identifier needs to be expanded. Bill Long's Yes with Comment on F08/0082: As Van pointed out, the discussion refers to READ(FORMATTED) whereas the example program has WRITE(FORMATTED). Changing the discussion text to WRITE(FORMATTED) is the simpler fix. Van Snyder's Yes with Comment vote on F08/0082: "READ(FORMATTED)" in the penultimate paragraph of the question ought to be "WRITE(FORMATTED)", or the opposite change ought to be made in the program. Result: Accept Bill's change. F08/0082 passes as amended. ---------------------------------------------------------------------- NUMBER: F08/0040 TITLE: MOVE_ALLOC for coarrays KEYWORDS: intrinsic, allocation DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Was it intended that MOVE_ALLOC be applicable to coarrays? ANSWER: Yes. A call to MOVE_ALLOC on coarrays might involve the deallocation of a coarray, therefore MOVE_ALLOC needs to be an image control statement. Also, the coranks of FROM and TO need to be the same. Edits are supplied to correct this. DISCUSSION: It might appear that C541 which says "An entity with the INTENT(OUT) attribute shall not be an allocatable coarray ..." might prohibit MOVE_ALLOC from operating on coarrays; however, this constraint applies to user-defined procedure not to intrinsic procedures. An edit is supplied to clarify C541. EDITS to 10-007r1: [97:13] In 5.3.10 INTENT attribute, C541, Change "An entity" to "A dummy argument of a nonintrinsic procedure". {Clarify the constraint.} [188:23+] In 8.5.1 Image control statements, paragraph 2, insert new bullet point before the STOP statement one, "- a CALL statement that invokes the intrinsic subroutine MOVE_ALLOC with coarray arguments;" [372;18] In 13.7.118p3 MOVE_ALLOC, FROM argument, "type and rank" -> "type, rank, and corank". {Edit is not necessary, but makes it more readable.} [372:19] In 13.7.118p3 MOVE_ALLOC, TO argument, After "same rank" insert "and corank". [372:29+] 13.7.118, p6+ Insert new paragraph immediately before "Example:" "When a reference to MOVE_ALLOC is executed for which the FROM argument is a coarray, there is an implicit synchronization of all images. On each image, execution of the segment (8.5.2) following the CALL statement is delayed until all other images have executed the same statement the same number of times." SUBMITTED BY: John Reid HISTORY: 10-200 m193 F08/0040 submitted 10-200r1 m193 Answer edited - Passed by J3 meeting 11-129 m194 Passed as amended by J3 letter ballot #22 10-254 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1889 m197 Failed WG5 ballot 2 N1877 12-139 m197 Revised answer - passed J3 meeting 12-165r2 m198 Failed J3 letter ballot #25 12-147 12-168 m198 Revised edits, added discussion section. 12-168r1 m198 Fixed typo - passed J3 meeting 12-196 m199 Passed as amended by J3 letter ballot #26, 12-184 ---------------------------------------------------------------------- NUMBER: F08/0074 TITLE: Implicit type in BLOCK construct KEYWORDS: IMPLICIT, BLOCK DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider Program m198_1 Implicit Complex(a-z) Logical x x = .True. Block Dimension x(2) x = 3 Print *,x End Block End Program Is this standard-conforming, and if so, what is the type of the X inside the BLOCK construct? The Fortran 2008 standard specifies the implicit mapping in program units, interface bodies, internal procedures, and module procedures, at 5.5p3, but does not specify the implicit mapping in a BLOCK construct. ANSWER: This was intended to be standard-conforming; the type of X is COMPLEX. An edit is provided to remedy this omission. EDIT: [109:16] In 5.5p3, last sentence, After "and the default for" change "an internal or module procedure" to "a BLOCK construct, internal subprogram, or module subprogram". This makes the whole sentence read "If a mapping is not specified for a letter, the default for a program unit or an interface body is default integer if the letter is I, J, ..., or N and default real otherwise, and the default for a BLOCK construct, internal subprogram, or module subprogram, is the mapping in the host scoping unit." SUBMITTED BY: Malcolm Cohen HISTORY: 12-151 m198 F08/0074 submitted. 12-151r1 m198 Revised edit. 12-151r2 m198 Clarified answer, passed J3 meeting. 12-196 m199 Passed by J3 letter ballot #26, 12-184 ------------------------------------------------------------------------ NUMBER: F08/0075 TITLE: Pointer function reference as variable in assignment KEYWORDS: Pointer function, assignment, defined operator DEFECT TYPE: Erratum STATUS: J3 consideration in progress 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. Edits are supplied to remove the ambiguities. EDITS: [45:7] 3.3.1p1 append new sentence "The first nonblank character of a statement that is not part of a statement shall not be a digit." [212:2+] 9.6.1, After R910, insert constraint "C909a (R910) shall not begin with an operator." 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. Malcolm Cohen's No vote on F08/0075: (Note that the edit is wrong - missing 'label' after the second statement – but that is not the reason for voting NO.) Even though a '.ADDRESS.' operator might look 'cool', I have come to the conclusion that allowing operator syntax to denote variables is a mistake. The standard has various restrictions on operators to reduce the ability to obfuscate your code, e.g. arguments are required to be INTENT(IN). The purpose of operator syntax was to allow user-defined algebra, not junk coding. There is no functionality provided by this feature that is not adequately served, with less obfuscation, by function reference syntax. The correct fix for this interp is to acknowledge our mistake in permitting this syntax to occur at all anywhere, and changing R602 and C602 to R602 variable is designator or function-reference C602 (R602) function-reference shall have a data pointer result. Note that a less extreme viewpoint would be to allow the operator syntax except as the variable in an assignment statement (or READ statement). That would be a better solution than the nitpicky syntax tweaks that are the current proposed solutions to this interp and the next, but would not be as consistent as disallowing this problematic syntax entirely. Result: A new answer and edits need to be prepared => F08/0075 fails. ---------------------------------------------------------------------- NUMBER: F08/0076 TITLE: Pointer function reference in READ KEYWORDS: Pointer function reference, READ, defined operator DEFECT TYPE: Erratum STATUS: Subsumed by F08/0075. QUESTION: 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. An edit is supplied to remove the ambiguity in the current standard. ANSWER: This is another example of the same problem as F08/0075, viz syntactic ambiguity caused by the F2008 feature "operator syntax for variable denotation". Therefore this interpretation request is subsumed by F08/0075. EDITS: See F08/0075. SUBMITTED BY: Van Snyder HISTORY: 12-150 m198 F08/0076 submitted 12-150r1 m198 Revised answer and edits, passed J3 meeting 12-196 m199 Subsumed by F08/0075, J3 letter ballot #26, 12-184 Result: This is another instance of the same problem (syntactic ambiguity) caused by the same feature (operator syntax for variable denotation) as F08/0075, so needs to be answered together with F08/0075, => example will be added to F08/0075, and F08/0076 is therefore subsumed by F08/0075. ---------------------------------------------------------------------- NUMBER: F08/0077 TITLE: Function references as variables in DATA statements KEYWORDS: function, reference, DATA DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: The Fortran 2008 standard extended the syntax of variables to allow references to functions to be variables (6.2, 117:13,15). Because of that extension, a function reference may appear as a (5.4.7, 104:15). For example, the program PROGRAM DATA REAL, TARGET :: X DATA PF()/1.0/ CONTAINS FUNCTION PF() REAL, POINTER :: PF PF => X END FUNCTION END satisfies the syntax rules and constraints of Fortran 2008. Was this intended? ANSWER: References to function were not intended to be allowed as s. An edit is supplied to correct this oversight. EDIT: [5.4.7, 104:26-27] Replace "In a that is a , each subscript, section subscript, substring starting point and substring ending point shall" with "A that is a shall be a , not an . Each subscript, section subscript, substring starting point, and substring ending point in the shall" SUBMITTED BY: Robert Corbett HISTORY: 12-153 m198 F08/0077 submitted 12-153r1 m198 Revised edits, passed J3 meeting 12-196 m199 Passed J3 letter ballot #26, 12-184 ---------------------------------------------------------------------- NUMBER: F08/0078 TITLE: Are the IEEE values +0 and -0 distinguished KEYWORDS: IEEE, zero, IEEE_SUPPORT_DATATYPE DEFECT TYPE: Clarification STATUS: Passed by J3 letter ballot QUESTION: Suppose the value of IEEE_SUPPORT_DATATYPE is true for arguments of some kind type parameter values for a processor. Is the processor required to distinguish between the real values +0 and -0 if the kind type parameter value of those zeros is among the kind type parameter values for which IEEE_SUPPORT_DATATYPE is true? ANSWER: No, the processor is not required to distinguish between positive and negative zero. DISCUSSION: If IEEE_SUPPORT_DATATYPE is true, IEEE_COPY_SIGN is required to behave differently with positive and negative zero representations; however this is because the IEEE_COPY_SIGN function copies the "sign bit" of the underlying representation, and in this it is acting in the same manner as the TRANSFER intrinsic. This means that even on a processor that does not distinguish between positive and negative zero in the places where the Fortran standard has different behaviour depending on that distinction (viz I/O and the SIGN intrinsic), the processor can still provide the IEEE features and the user can still access the IEEE copysign functionality using the IEEE_COPY_SIGN function. EDITS: None. SUBMITTED BY: Robert Corbett HISTORY: 12-154 m198 F08/0078 submitted 12-154r1 m198 Revised answer, passed J3 meeting 12-196 m199 Passed by J3 letter ballot #26, 12-184 ---------------------------------------------------------------------- NUMBER: F08/0079 TITLE: NAMELIST and type specification KEYWORDS: NAMELIST DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Q1. Consider Module m198_002a Type t Real c Contains Procedure :: fwrite => fwrite_t Generic :: Write(Formatted) => fwrite End Type Type,Extends(t) :: t2 Logical ok End Type Contains Subroutine fwrite_t(dtv,unit,iotype,v_list,iostat,iomsg) Class(t),Intent(In) :: dtv Integer,Intent(In) :: unit,v_list(:) Character(*),Intent(In) :: iotype Integer,Intent(Out) :: iostat Character(*),Intent(InOut) :: iomsg If (iotype/='NAMELIST' .And. iotype/='LISTDIRECTED') & Stop 'NYI' Select Type (dtv) Class Is (t) Write(unit,*,Iostat=iostat,Iomsg=iomsg) 'T',dtv%c Class Is (t2) Write(unit,*,Iostat=iostat,Iomsg=iomsg) 'T2',dtv%c,dtv%ok End Select End Subroutine End Module Program test Use m198_002a Class(t),Pointer :: x ! A Namelist/n/x Allocate(x,Source=t(1.5)) ! B Write (*,n) Allocate(x,Source=t2(1.5,.True.)) ! C Write (*,n) End Program The standard requires, at 5.6p5, "A namelist group object ... shall have its type ... specified by previous specification statements ...". The declared type of X is specified by the type declaration marked "! A", but the dynamic type of X is specified by one of the assignment statements (either "! B" or "! C"). Is this program intended to be standard-conforming? Q2. Consider Module m198_002b Use Iso_Fortran_Env Type t(p) Integer,Kind :: p Real(Selected_Real_Kind(p)) c Contains Procedure :: fwrite => fwrite_t Generic :: Write(Formatted) => fwrite End Type Type,Extends(t) :: t2(k) Integer,Kind :: k Integer(k) e End Type Contains Subroutine fwrite_t(dtv,unit,iotype,v_list,iostat,iomsg) Class(t(6)),Intent(In) :: dtv Integer,Intent(In) :: unit,v_list(:) Character(*),Intent(In) :: iotype Integer,Intent(Out) :: iostat Character(*),Intent(InOut) :: iomsg If (iotype/='NAMELIST' .And. iotype/='LISTDIRECTED') & Stop 'NYI' Select Type (dtv) Class Is (t(6)) Write(unit,*,Iostat=iostat,Iomsg=iomsg) 'T',dtv%c Class Is (t2(6,int32)) Write(unit,*,Iostat=iostat,Iomsg=iomsg) 'T2',dtv%c,dtv%e Class Is (t2(6,int64)) Write(unit,*,Iostat=iostat,Iomsg=iomsg) 'T2',dtv%c,dtv%e End Select End Subroutine End Module Program test Use m198_002b Class(t(6)),Pointer :: x ! A Namelist/n/x Allocate(x,Source=t(6)(1.5) ! B Write (*,n) Allocate(x,Source=t2(6,int32)(1.5,2**30)) ! C Write (*,n) Allocate(x,Source=t2(6,int64)(1.5,2**60)) ! D Write (*,n) End Program The standard required, at 5.6p5, "A namelist group object ... shall have its ... type parameters ... specified by previous specification statements ...". This was modified by Corrigendum 1 to read "A namelist group object ... shall have its ... kind type parameters ... specified by previous specification statements ...". The declared type of X has the kind type parameter P, and this is duly specified at the statement marked "! A", but the dynamic type of X after either of the assignment statements marked "! C" or "! D" has an additional kind type parameter K, and this specification does not precede the NAMELIST statement. Is this program intended to be standard-conforming? Q3. Consider the program consisting of the same module as in Q2, but with the revised main program: Program test Use m198_002b Implicit Type(t(6)) (a-z) Namelist/n/x Class(t(6)),Pointer :: x ! A Allocate(x,Source=t(6)(1.5)) ! B Write (*,n) Allocate(x,Source=t2(6,int32)(1.5,2**30)) ! C Write (*,n) Allocate(x,Source=t2(6,int64)(1.5,2**60)) ! D Write (*,n) End Program The standard says at 5.6p5 "If a namelist group object is typed by the implicit typing rules, its appearance in any subsequent type declaration statement shall confirm the implied type and type parameters." The declared type of X, and its declared kind type parameters, are specified at "! A", and these are indeed the same type and type parameters that appear in the IMPLICIT statement, but X is CLASS(T(6)) not TYPE(T(6)). Is this program intended to be standard-conforming? Q4. Consider Module m198_002d Use Iso_Fortran_Env Type t(mp) Integer,Len :: mp Integer c(mp) Contains Procedure :: fwrite => fwrite_t Generic :: Write(Formatted) => fwrite End Type Type,Extends(t) :: t2(mk) Integer,Len :: mk Integer e(mk) End Type Contains Subroutine fwrite_t(dtv,unit,iotype,v_list,iostat,iomsg) Class(t(*)),Intent(In) :: dtv Integer,Intent(In) :: unit,v_list(:) Character(*),Intent(In) :: iotype Integer,Intent(Out) :: iostat Character(*),Intent(InOut) :: iomsg If (iotype/='NAMELIST' .And. iotype/='LISTDIRECTED') & Stop 'NYI' Select Type (dtv) Class Is (t(*)) Write(unit,*,Iostat=iostat,Iomsg=iomsg) 'T',dtv%c Class Is (t2(*,*)) Write(unit,*,Iostat=iostat,Iomsg=iomsg) 'T2',dtv%c,'E',dtv%e End Select End Subroutine End Module Program test Use m198_002d Implicit Type(t(1)) (a-z) Namelist/n/x Class(t(:)),Pointer :: x ! A Allocate(x,Source=t(1)([15])) ! B Write (*,n) Allocate(x,Source=t2(2,4)([15,30],[3,2,1,0])) ! C Write (*,n) Allocate(x,Source=t2(2,5)([15,30],[4,3,2,1,0])) ! D Write (*,n) End Program The declared type of X, and its declared kind type parameters (of which there are none), are specified at "! A", and these are indeed the same type and kind type parameters that appear in the IMPLICIT statement, but the length type parameters are not the same. However, after Corrigendum 1 there is no requirement for prior specification of the length type parameters, so it is unclear whether the requirement for confirmation is intended to apply to length type parameters as well as kind type parameters. Is this program intended to be standard-conforming? ANSWER: A1. This program was intended to be conforming. The requirement for prior specification of the type was intended to mean the declared type only. An edit is supplied to clarify the intent. A2. This program was intended to be conforming. The requirement for prior specification of the kind type parameters was intended to apply only to type parameters of the declared type. An edit is supplied to clarify the intent. A3. This program is conforming. A4. This program is not conforming. If the IMPLICIT statement were Implicit Type(t(:)) (a-z) it would be conforming. No edit is necessary. EDITS: [111:19-20] In 5.6 paragraph 5, Change what was originally "type, type parameters, and shape" but which was changed by Corrigendum 1 to "type, kind type parameters, and rank" to "declared type, kind type parameters of the declared type, and rank". {It would be nice to be able to say "declared kind type parameters" but that phrase it not used in the standard at present.} SUBMITTED BY: Malcolm Cohen HISTORY: 12-157 m198 F03/0079 submitted with wrong question. 12-157r1 m198 Revised question, answer, and edits. 12-157r2 m198 Revised examples, answer. 12-157r3 m198 Fixed typos in examples, passed J3 meeting. 12-196 m199 Passed as amended by J3 letter ballot #26, 12-184 ---------------------------------------------------------------------- NUMBER: F08/0080 TITLE: Array constructors with polymorphic values KEYWORDS: Array constructor, polymorphic DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Q1. Consider Program m198_003a Type :: t Real a End Type Type,Extends(t) :: t2 Real b End Type Class(t),Allocatable :: x,y Allocate(x,Source=t2(1,2)) Allocate(y,Source=t(3)) Print *, [ t :: x, y ] End Program Constraint C4105 of the standard, page 85, says "If specifies a derived type, all expressions in the array constructor shall be of that derived type ..." However, although the declared type of X is type T, its dynamic type is type T2. Does this program conform to the standard? Q2. Consider Program m198_003b Type :: t Real a End Type Type,Extends(t) :: t2(n) Integer,Len :: n Real b(n) End Type Class(t),Allocatable :: x,y,z Allocate(x,Source=t2(3)(1,[2,3,4])) Allocate(y,Source=t(5)) Allocate(z,Source=t2(4)(6,7)) Print *, [ x, y, z ] End Program 4.8 paragraph 2 of the standard says "If is omitted, each expression shall have the same length type parameters; in this case, the declared type and type parameters of the array constructor are those of the expressions." However, although the length type parameters of the declared types of X, Y and Z are the same (all being the empty set), the length type parameters of the dynamic types are not: Y has no dynamic length type parameters, and the value of the dynamic length type parameter N of X and Z are different. Does this program conform to the standard? Q3. Consider Program m198_003c Type,Abstract :: t Real a End Type Type,Extends(t) :: t2 Real b End Type Class(t),Allocatable :: x,y Allocate(x,Source=t2(1,2)) Allocate(y,Source=t2(3,4)) Print *, [ x, y ] End Program This appears to conform to the standard, but the dynamic type of the array constructor is the same as its declared type, and is therefore abstract. Is this intended to conform to the standard? ANSWER: A1. This program was intended to be conforming. An edit is supplied to clarify the standard. A2. This program was intended to be conforming. An edit is supplied to clarify the standard. A3. This program was not intended to be conforming. An edit is supplied to add the necessary requirement to the standard. EDITS: [85:8-9] In 4.8, C4105, Change "all expressions in the shall be of that derived type and" to "the declared type of each expression in the shall be that derived type and". [85:10+] In 4.8, after C4106, insert new constraint "C4106a (R472) The declared type of an shall not be abstract." [85:13-14] In 4.8p2, Change "each expression in the array constructor shall have the same length type parameters;" to "corresponding length type parameters of the declared type of each expression shall have the same value;". SUBMITTED BY: Malcolm Cohen HISTORY: 12-159 m198 F03/0080 submitted 12-159r1 m198 Revised edits. 12-159r2 m198 Fixed typo, passed J3 meeting. 12-196 m199 Passed as amended by J3 letter ballot #26, 12-184 ---------------------------------------------------------------------- NUMBER: F08/0081 TITLE: Deallocation error handling KEYWORDS: FINAL, DEALLOCATE, ALLOCATABLE DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Q1. Consider Module m198_005a Implicit None Type t Character(80) :: name = 'Nameless' Contains Final :: tzap End Type Private tzap Contains Subroutine tzap(x) Type(t) x Print *,'Goodbye ',Trim(x%name) End Subroutine Subroutine test(p) Type(t),Pointer :: p Integer istat Deallocate(p,Stat=istat) If (istat/=0) Print *,'Deallocation error',istat End Subroutine End Module Program testprog Use m198_005a Type(t),Target :: x Type(t),Pointer :: y Allocate(y) x%name = 'target_x' y%name = 'allocated_y' Call test(y) y => x Call test(y) End Program Is this program standard-conforming, and if so, does it print Goodbye target_x ? Note that 4.5.6.3 says "When a pointer is deallocated its target is finalized." This could be interpreted as meaning "successfully deallocated" in which case the finalizer would not be invoked, or it could be interpreted as including any unsuccessful deallocation attempt, in which case the finalizer would be invoked. Q2. Consider Program m198_005b Implicit None Type t Character(:),Allocatable :: name End Type Type(t),Target :: x Type(t),Pointer :: y Integer :: istat Allocate(y) x%name = 'target_x' y%name = 'allocated_y' Deallocate(y) y => x Deallocate(y,Stat=istat) If (.Not.Allocated(x%name)) Print *,'x is now nameless' End Program 6.7.3.2 says "When a variable of derived type is deallocated, any allocated allocatable subobject is deallocated." Again, this does not specify whether this applies only to successful deallocation. Is this program standard-conforming, and does it print x is now nameless ? ANSWER: Whether the final subroutine is invoked, and whether any allocated allocatable subobject is deallocated, is processor dependent. EDITS: [76:10] Append new sentence to 4.5.6.3p2 {after F08 corrigendum 1} "If an error condition occurs during deallocation, it is processor dependent whether finalization occurs." [131:12] Append new sentence to 6.7.3.2p8 "If an error condition occurs in deallocation, it is processor dependent whether an allocated allocatable subobject is deallocated." [459:33+] In A.2, After "whether and when an object is finalized ... (4.5.6.3);" Insert new bullet point "whether an object is finalized by a deallocation in which an error condition occurs (4.5.6.3);" [460:5+] In A.2, After "the order ... event described in 6.7.3.2;" Insert new bullet point "whether an allocated allocatable subobject is deallocated when an error condition occurs in the deallocation of an object (6.7.3.2);" SUBMITTED BY: Malcolm Cohen HISTORY: 12-160 m198 F03/0081 submitted 12-160r1 m198 Revised question & answer, passed J3 meeting 12-196 m199 Passed as amended by J3 letter ballot #26, 12-184 ---------------------------------------------------------------------- NUMBER: F08/0082 TITLE: Generic identifier and dtv arguments KEYWORDS: Generic, Defined i/o DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider Module m198_010 Interface g Module Procedure mp1, mp2 End Interface Type t Real c End Type Interface Write(Formatted) Module Procedure fwrite End Interface Contains Subroutine mp1(a,dtv) Integer,Intent(Out) :: a Integer,Intent(In) :: dtv a = dtv End Subroutine Subroutine mp2(b,dtv) Real,Intent(Out) :: b Integer,Intent(In) :: dtv End Subroutine Subroutine fwrite(dtv,unit,iotype,v_list,iostat,iomsg) Class(t),Intent(In) :: dtv Integer,Intent(In) :: unit,v_list(:) Character(*),Intent(In) :: iotype Integer,Intent(Out) :: iostat Character(*),Intent(InOut) :: iomsg Write(unit,*,Iostat=iostat,Iomsg=iomsg) 'T',dtv%c End Subroutine End Module After corrigendum 1, constraint C1214 reads C1214 Within the scope of a , if two procedures have the same generic identifier, their \cf{dtv} arguments (9.6.4.8.3) shall be distinguishable. The scope of the WRITE(FORMATTED) generic-spec is the entire module M198_010, and within that module, the two procedures MP1 and MP2 have the same identifier (G), but their DTV arguments are not distinguishable. This clearly violates the new C1214, but the module conforms to the Fortran 2003 standard. Is this module intended to be standard-conforming? ANSWER: Yes, this was intended to be standard-conforming. An edit is supplied to correct the typographical error in Corrigendum 1. EDITS: [286:12-13] In the new version of C1214 from Corrigendum 1, change "the same" to "that". SUBMITTED BY: Malcolm Cohen HISTORY: 12-169 m198 F03/0082 submitted 12-169r1 m198 Fixed typo in the example, passed J3 meeting 12-196 m199 Passed as amended by J3 letter ballot #26, 12-184 ----------------------------------------------------------------------