J3/05-180 Date: 29-Apr-2005 To: J3 Members From: /interp/Stan Whitlock Subj: Results of the WG5 interp ballot N1612/N1617 Nov-2004 Here are the results of WG5 ballot on Fortran 95 and Fortran 2003 interpretations that was held in November, 2004.The ballot is in WG5 paper N1612 and the results are in WG5 paper N1617. * F95 interps that passed unconditionally will be marked "Passed by WG5 ballot" in the 006A * F95 interps that had acceptible comments that did not change the technical content will be so changed and marked "Passed by WG5 ballot" in the 006A * F95 interps that failed will be marked "J3 consideration in progress" in the 006A and be returned to J3 * F03 interps that passed unconditionally will be marked "Passed by WG5 ballot" in the 006A and will be part of the first Fortran 2003 Corrigendum {see WG5/N1620} * F03 interps that had acceptible comments that did not change the technical content will be so changed and marked "Passed by WG5 ballot" in the 006A and will be part of the first Fortran 2003 Corrigendum {see WG5/N1620} * F03 interps that failed will be marked "J3 consideration in progress" in the 006A and be returned to J3 The result of the WG5 interpretations ballot, N1612, are below. Here is the key for the "Result" line: Y Vote passes unconditionally. C Vote passes, subject to J3 considering the comments and reasons and making no change that alters the technical content. N Vote fails. Returned to J3 for further work. Here is the key for the "006A" line: P interp failed - returned to J3 for further processing W interp passed WG5 ballot Z interp passed WG5 ballot with minor non-technical change Here is the key for the "F03" line: 3 the edit to F95 is already in Fortran 2003 N1601 9 an edit to Fortran 2003 based on the F95 interp is proposed in N1620 with changes based on ballot comments + an edit to Fortran 2003 based on the F95 interp is proposed in N1620 004 006 008 017 023 030 031 068 074 078 096 098 102 103 104 Cohen C Y Y Y Y C C Y C C C N N C Y Ingrassia Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y James Y C C N C N N C N C N Y C N Y Maine N N Y N N N N N N N N N N N N Muxworthy Y Y Y Y Y Y Y Y Y C Y Y C Y Y North Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Reid C Y Y Y Y N C Y C N N N N N Y Snyder Y Y Y Y Y Y Y Y N Y Y Y Y Y Y Whitlock Y Y Y Y Y Y Y Y Y Y Y N N Y Y Result C C C C C C C C C C C N N C C 006A W W Z W Z W Z W P W Z P P W W f03 9 9 + 3 F90/ F90/ F90/ F90/ F90/ F90/ F90/ F90/ F90/ 049 070 096 140 180 206 207 208 210 JP-24 Cohen C Y C Y C Y C Y Y C Ingrassia Y Y Y Y Y Y Y Y Y Y James Y N Y Y N Y C Y Y N Maine N N N N N N N N Y N Muxworthy Y Y Y Y Y Y C Y Y C North Y Y Y Y Y Y Y Y Y Y Reid N Y N Y N Y N Y Y N Snyder Y Y Y Y Y Y Y Y Y Y Whitlock Y Y Y Y Y Y Y Y Y Y Result C C C C C C C C Y C 006A W W W W Z Z Z W W W F03 9 3 F03/ F03/ F03/ F03/ F03/ F03/ F03/ F03/ F03/ F03/ 001 002 003 004 005 006 007 009 010 011 Cohen Y C N N Y Y Y Y Y Y Ingrassia Y Y Y Y Y Y Y Y Y Y James Y Y N N Y Y Y Y Y Y Maine Y Y Y Y Y Y Y Y Y Y Muxworthy Y Y C C Y Y Y Y Y Y North Y Y Y Y Y Y Y Y Y Y Reid Y C N N Y Y Y Y Y Y Snyder Y Y Y Y Y Y Y Y Y Y Whitlock Y Y N N Y Y Y Y Y Y Result Y C N N Y Y Y Y Y Y 006A W Z P P W W W W W W F03 + + + + + + F03/ F03/ F03/ F03/ 013 014 015 016 Cohen Y Y Y Y Ingrassia Y Y Y Y James Y Y Y Y Maine Y Y Y Y Muxworthy Y Y Y C North Y Y Y Y Reid Y Y Y Y Snyder Y Y Y Y Whitlock Y Y Y Y Result Y Y Y C 006A W W W W F03 + + + + Comments on YES votes and reasons for NO votes ...................................................................... Malcolm Cohen general comments Contrary to John's suggestion, I believe that the DEFECT TYPE field should not say "Fortran 95 Interpretation". This field contains information about the TYPE of the DEFECT, not about which standard is being complained about. The Fortran 95 interpretations should be referred to as F95/NNNNNN instead of just plain NNNNNN. Regardless of which standard was (originally) complained about, the interpretation request needs to address effects on the current standard (possibly as well as the effects on the original one). I note that the very recent publication of F2003 in between the final J3 ballot on most of these interpretations and the WG5 ballot has lead to this information being out of date in many cases. I do not believe that this simple procedural infelicity (scheduling error) means that we should reject the interpretations, provided that the information becomes available during the ballotting process and is uncontroversial. I have noted this information below. I'll also note that FAILing an interp which contains edits already applied to F2003 implies that we should consider removing those edits from F2003. So saying that we should defeat a (F90 or F95) interp because the editor assumed that the interp would pass and therefore already applied the edits to F2003 makes no sense to me at all. Let's avoid unnecessary work on the already-correct interpretations so we can get on with the backlog of difficult ones. ...................................................................... John Reid general comments Please note that this is a personal vote and does not represent a position as Convener. I have not let this affect my votes, but I think the DEFECT TYPE for items 000004 to 000104, F90/000049, F90/000070, F90/000206 to F90/000210 and JP- 24 should be 'Fortran 95 interpretation', since the references are to Fortran 95. Similarly, I think the DEFECT TYPE for items F90/000096, F90/000140, and F90/000180 should be 'Fortran 90 interpretation' or the words changed to refer to Fortran 95. And it would not hurt to label each F03 item as 'Fortran 2003 interpretation'. We can no longer issue a corrigendum for Fortran 95, but the fact of the matter is that no compilers for Fortran 2003 are available yet so our workhorse is Fortran 95. Therefore, interpreting Fortran 95 and issuing carefully considered edits for it is a very useful function. It would not be helpful at this time to rephrase the questions in terms of Fortran 2003, but where edits are needed to Fortran 95, we should consider whether the corresponding edits are needed to Fortran 2003. ...................................................................... 000004 Value returned by MAXVAL/MINVAL Malcolm Cohen's YES comment for F95/000004: The last paragraph should read "Fortran 2003 uses similar wording in MAXVAL and MINVAL to that in Fortran 95." Richard Maine's NO vote for 004: The answer cites 13.14.39, which does not exist in f2003. This citation should either be changed or explicitly documented as referring to f95 (which I presume it does - I didn't check). The technical content is otherwise ok. John Reid's YES comment for 000004: I would like to delete the final paragraph 'Fortran 2003 uses ...' since it is not correct. Result: F95 interp 000004 passes WG5 ballot but delete the final paragraph in the NOTE about F2003. ...................................................................... 000006 Character length specification of a function result Rob James' YES comment for 000006: For Fortran 2003, the answer should refer to page 41, not 51. Richard Maine's NO vote for 006: The interp explicitly discusses f95, without even mentioning that the same principles apply to f2003. The technical content is otherwise ok. Result: F95 interp 000006 passes WG5 ballot with no change. ...................................................................... 000008 Optional arguments to MAX/MIN Rob James' YES comment for 000008: The question refers to Section 13.3 [217:27+] of Fortran 95. It should be made clear that this refers to Fortran 95, and not Fortran 2003. Result: F95 interp 000008 passes WG5 ballot but add "of Fortran 95" after the reference to Section 13.3 in the QUESTION. ...................................................................... 000017 Characteristics of an array function result Rob James' NO vote for 000017: We should be quoting Fortran 2003 for this answer. The correct quote is from 12.2.2 [257:4-6]: If a type parameter of a function result or a bound of a function result array is not an initialization expression, the exact dependence on the entities in the expression is a characteristic. Richard Maine's NO vote for 017: The interp explicitly discusses f95, without even mentioning whether the same principles apply to f2003. I'm not sure whether it is relevant or not. Result: F95 interp 000017 passes WG5 ballot with no change. ...................................................................... 000023 Termination of the previous record by a WRITE statement Rob James' YES comment for 000023: We should make it clear that the question is referring to 9.2.1.3.2 from Fortran 95. This section number does not exist in Fortran 2003. The corresponding section from Fortran 2003 is 9.2.3.2. Also, the answer to the first question should refer to section 9.2.3.2 [176:8-9] of Fortran 2003, and the answer to the second question should refer to 10.7.1 instead of 10.6.1. Richard Maine's NO vote for 023: The interp references 9.1.3.2, which doesn't exist in f2003. There is no indication that this might be a reference to f95. Likewise for other section and page/line citations. Result: F95 interp 000023 passes WG5 ballot but add "of Fortran 95" after the reference to Section 9.2.1.3.2 in the ANSWER. ...................................................................... 000030 Ordering requirements on definition of specification functions Malcolm Cohen's YES comment for F95/000030: The edits should also be applied to F2003, at 04-007:[127:33+] (immediately before Note 7.11) and [126:19+] (immediately before Note 7.10) respectively. {NOTE: In F2003, Specification expressions are defined before Initialization expressions, thus the 1st edit needs to be applied later in the document than the 2nd edit.} Rob James' NO vote for 000030: The edits are incorrect for Fortran 2003. In Fortran 2003, the initialization expression edit should go before note 7.11, and the specification expression edit should go before note 7.10. Richard Maine's NO vote for 030: The interp references 7.1.6.1, which doesn't exist in f2003. There is no indication that this might be a reference to f95. Likewise for other section and page/line citations. Notes 7.14 and 7.16 exist, but are implausible places for the edits. John Reid's NO vote for 000030: The same edits are needed in N1601 before notes 7.10 and 7.11. Result: F95 interp 000030 passes WG5 ballot with no change. The same edit will be made to Fortran 2003 as part of N1620. ...................................................................... 000031 Association of pointer function result with INTENT(OUT) dummy argument (subsumed by 000074) Malcolm Cohen's YES comment for F95/000031: I dislike the suggestion that this interpretation be given an answer without any explanation whatsoever. Either the interp is subsumed (in which case it is correct as it stands, and warrants no discussion or unexplained "answers") or not subsumed, in which case it needs a complete answer and discussion of its very own. Rob James' NO vote for 000031: Since I'm voting NO on 000074, it wouldn't seem right for me to approve of an answer that says "See the answer to interpretation #74". Richard Maine's NO vote for 031: This appears to be an f95 interp. If it is worth listing at all as an f2003 one, even subsumed, it should at least mention that its citations are to f95 instead of f2003. Also, I voted against interp 74, and I don't think we can count this one as being closed by interp 74 if interp 74 isn't closed. John Reid's YES comment for 000031: I would like to add at the beginning of the ANSWER 'The program does not conform to the standard.' Result: F95 interp 000031 is still subsumed by F95 interp 000074, which did not pass WG5 ballot. Add John Reid's comment to the ANSWER to 000031. ...................................................................... 000068 Asterisks as I/O units Rob James' YES comment forYES comment on 000068: The answer should refer to Fortran 2003 instead of Fortran 95. Richard Maine's NO vote for 068: This interp is explicitly about f95. Furthermore, in this case, the answer is distinctly different in f2003. I don't see how we can claim this to be an f2003 interp as is. Just changing the citations won't fix this. Result: F95 interp 000068 passes WG5 ballot with no change. ...................................................................... 000074 TARGET dummy arguments and POINTER expressions Malcolm Cohen's YES comment for F95/000074: The suggested edit of making part of Annex A into normative text is a reasonable one for clarification of the next standard. I do not think it should be done as part of this interp; in particular, the defining statement lacks generality. It implies (correctly), but does not say outright, that an entity which is not a variable is not definable; if we are going to the effort of making an edit to clarify the standard we should go whole hog and make it completely clear. Rob James' No vote for 000074: The answers quote Fortran 95 instead of Fortran 2003. The second sentence quoted in answer 1 does not exist in Fortran 2003, and the first sentence is in 5.1.2.7. Answer 2 should reference 12.4.1.2 instead of 12.4.1.1, and answer 3 should quote slightly different text from 12.4.1.2 (not 12.4.1.1) at [270:5-9] (not [200:38-42]). Richard Maine's NO vote for 074: This interp references sections that exist in f2003, but do not contain the cited material. There is no indication that these might be references to f95. John Reid's YES comment for 000074: I think the edit of copying the first sentence of the definition [295:20-21] to 2.5.4 (2.5.5 in N1601) is desirable. Van Snyder's NO vote for 000074: The analysis leading to the answer to this interpretation request rests upon ignoring [F95:200:30-32]: "If the dummy argument is not a pointer and the corresponding actual argument is a pointer, the actual argument shall be currently associated with a target and the dummy argument becomes argument associated with that target." In particular, the dummy argument *does not* become associated with the function result. This means that neither [F95:201:19-20] ("If a nonpointer dummy argument has INTENT (OUT) or INTENT (INOUT), the actual argument shall be definable.") nor the cited passage from 12.5.2.1 ("A dummy data object whose intent is not specified is subject to the limitations of the data entity that is the associated actual argument. That is, a reference to the dummy data object may occur if the actual argument is defined and the dummy data object may be defined if the actual argument is definable.") apply. The reasoning in the answer to question 1 ("... the actual argument is a function result...") is therefore not germane: The actual argument *is not* a function result! For the same reason, the cited text from 12.4.1.1 ("If a dummy argument has INTENT(OUT) or INTENT(INOUT), the actual argument shall be definable.") is not germane. If a pointer is associated with a target (required by [F95:200:30-32]), the definability requirement is that the *target* be definable -- which it is. The "definable" requirement *does not* apply to the actual argument's pointer association, which is the function's result. It is therefore a pointless and gratuitously unhelpful inconsistency to prohibit a reference to a function that returns a pointer result to be associated with a nonpointer dummy argument that has INTENT (INOUT) or INTENT (OUT). I agree with the answer to question 3, and that no edits are necessary. One might argue that the answer I propose necessarily leads to left-hand functions, but this is not the case: The syntax and associated constraints prohibit function references, even those that return pointers, from appearing on the left side of assignment statements, or as an input item. The question what such things would mean is therefore meaningless. Result: F95 interp 000074 does not pass WG5 ballot so is returned to J3 for more processing. ...................................................................... 000078 Resolving generic procedure references Malcolm Cohen's YES comment for F95/000078: The edit should be applied to F2003, at 04-007:[278:5+] (immediately before 12.4.4.2). Rob James' YES comment for 000078: In Fortran 2003, this edit should be applied at [278:5+]. Richard Maine's NO vote for 078: The interp references sections that do not exist in f2003. There is no indication that these might be references to f95. David Muxworthy's YES comment for 000078: The edits should also be applied to F03 at 278:5+ John Reid's NO vote for 000078: The same edit is needed in N1601 at the end of 12.4.4.1. Result: F95 interp 000078 passes WG5 ballot but note that the similar edit to be made to Fortran 2003 as part of N1620 will add the text as item (5) instead of a new paragraph. ...................................................................... 000096 End-of-record and PAD Malcolm Cohen's YES comment for F95/000096: The edits for Fortran 95 should be [150:15] Replace "corresponding data edit descriptor" by "its corresponding data edit descriptors". [153:13-14] Replace "corresponding data edit descriptor" by "corresponding data edit descriptors". The edits marked for 03-007r2 have the correct page/line for 04-007. For Fortran 2003, [198:12] is the 8th paragraph of 9.5.3.4, and [218:6-7] is list item (1) in 9.10.3. NOTE: Although my comment is suggesting a change to an edit, it is so minor that I do not think it has any technical content or need to FAIL the interp (which restarts the whole process from the beginning, i.e. at least another year before we answer it!). Rob James' NO vote for 000096: The answer extensively cites page and line numbers from Fortran 95, and edits are given for both Fortran 95 and Fortran 2003. The answer should cite page and line numbers from Fortran 2003, and edits should only be given for Fortran 2003. Richard Maine's NO vote for 096: The interp references sections that do not exist in f2003. There is no indication that these might be references to f95. There are f2003 edits, but those edits cite 03-007r2, which is not the latest f2003 internal document. It looks to me like the pages and lines are still correct for the latest internal document, but the citation should be updated. John Reid's NO vote for 000096: 1. Delete '97-007r2' at the start of EDITS. [We do not do this for other edits.] 2. Separate the edits for 150 and 153 since 'its' is already present on 153. 3. Replace the reference to '03-007r2' to N1601. Result: F95 interp 000096 passes WG5 ballot but with the F95 edit changes recommended by Malcolm Cohen and the F03 edits removed. The F95 edits will be made to Fortran 2003 as part of N1620. ...................................................................... 000098 Are dummy functions returning assumed-length character legal? (duplicate of 000006) Malcolm Cohen's NO vote for F95/000098: I agree with John that there is an issue here which is not adequately covered by Interp F95/000006. However, I think that the suggestion that item (3) of 5.1.1.5 means that the program is invalid is without merit. A literal interpretation of item (3) means that even if subroutine SS3 declared dummy FF as being CHARACTER*5, the program would still be invalid since the name of the function is F, not FF. This would be a completely ridiculous result. Thus item (3) of 5.1.1.5 is faulty and an edit is required for it to handle (assumed-length) dummy functions at all. Richard Maine's NO vote for 098: This appears to be an f95 interp. If it is worth listing at all as an f2003 one, even as a dup, it should at least mention that its citations are to f95 instead of f2003. Also, I voted against interp 6. John Reid's No vote for 000098: This is different from interpretation 6 since the function has assumed character length, which means that item (3) of page 51 applies. Hence, I think the ANSWER should be The program does not conform with the standard because of the rule in item (3) of the list in 5.1.1.5. The function f is invoked from the scoping unit of ss3 within which the function name does not satisfy any of the required conditions. Stan Whitlock's NO vote on 000098: I agree with JohnR and Malcolm that interp 000006 doesn't cover this. Result: F95 interp 000098 does not pass WG5 ballot. It is not a duplicate of F95 interp 000006. It is returned to J3 for further processing. ...................................................................... 000102 mask-expr evaluated only once Malcolm Cohen's NO vote for F95/000102: The edits to F95 are faulty. The edit to [112:30-31] is without merit - it covers a WHERE statement outside of any WHERE construct (so the mask-expr *IS* going to be evaluated exactly once!). It is missing an edit to [113:20], which covers WHERE statements inside a WHERE construct, and for which therefore we do want to say "at most once". Fortran 2003 needs no edits - it does not have the faulty edit to the WHERE statement outside of a WHERE construct, and does have the missing edit for the WHERE statement inside of a WHERE construct. See 04-007:[147:1] and [147:16]. (The only correct F95 edit, that to [112:38], is at 04-007:[147:7] already.) Rob James' YES comment for 000102: The edits for Fortran 2003 are at [147:1] and [147:7]. Richard Maine's NO vote for 102: The cited line numbers don't exist on that page in f2003. There is no indication that these might be references to f95. David Muxworthy's YES comment for 000102: The edits should also be applied to F03 at 147:1 and 147:7 John Reid's NO vote for 000102: The first edit is needed in N1601 at [147:1]. The second has been done at [147:7]. Stan Whitlock's NO vote on 000102: I agree with Malcolm that the edits aren't right. Result: F95 interp 000102 does not pass WG5 ballot and is returned to J3 for further processing. ...................................................................... 000103 Derived type name DOUBLEPRECISION Malcolm Cohen's YES comment for F95/000103: The edit has already been applied to F2003. Rob James' NO vote for 000103: No edits should be given, as none are necessary for the current revision of the standard. Richard Maine's NO vote for 103: This makes no sense at all as an f2003 question. It is a question about wording that doesn't exist in f2003. The suggested "clarification" is exactly what f2003 already says. Also, the only hint that the whole thing is about f95 is the parenthetical acknowledgement that the fix is already in f2003. John Reid's NO vote for 000103: State that the edit has been done in N1601. Result: F95 interp 000103 passes WG5 ballot but remove the reference to the F2003 in EDITS. ...................................................................... 000104 Representation method of result of REAL Richard Maine's NO vote for 104: This interp specifically cites f95 (though you would have to know internal J3 document numbers to realize that). It makes no mention of f2003. Result: F95 interp 000104 passes WG5 ballot with no change. ...................................................................... F90/000049 Characteristics of function results Malcolm Cohen's YES comment for F90/000049: I don't think we should work on this one any more. Is 12 years not enough for someone to wait for an answer to their question? Anyway, I don't agree that M+M is necessarily different from M*2 (in fact it is not different for any machine with a Fortran 90 or later compiler). Mathematically, M*2 is indeed identical to M+M (that's what multiplication means). The vagaries of floating-point arithmetic form no part of the question, and indeed if they did they would doubtless fall immediately into the bottomless pit of "not defined by this standard". I see no merit in raising unanswerable questions that were not asked. Richard Maine's NO vote for f90/000049: The references section explicitly cites f90. There is no mention of whether it still applies to f2003. John Reid's NO vote for F90/000049: More work is needed on this item. At the moment, 'the way the value is determined' (end of answer 4) is not the same for M*2 as for M+M since one is done by multiplication and the other by addition, so this text is not consistent with the text that follows. On the other hand, we probably need the sequence of operations to be the same when floating- point arithmetic is involved (in Fortran 2003) since it is not associative. Is there any real value in allowing rearrangements such as M*2 for M+M? Might it not be better to say that the primaries of the expression and the sequence of operations that are applied to construct the value from the primaries are characteristics? Result: Work on F95 interp F90/000049 is declared done. F95 interp F90/000049 passes WG5 ballot with no change. ...................................................................... F90/000070 Characteristics specified by interface bodies Rob James' NO vote for F90/000070: A "possible Fortran 2003 edit" should not be given in a ballot for Fortran 2003 interpretations. The "possible Fortran 2003 edit" should either be made definite, or removed entirely. Richard Maine's NO vote for f90/000070: The references section explicitly cites f90. F2003 is mentioned only as an aside about a "possible edit". If this is actually an f2003 interp, then it needs to be a little more definitive than alluding to a possible edit. Result: F95 interp F90/000070 passes WG5 ballot but remove the aside about a "possible F2003 edit". ...................................................................... F90/000096 Definition of "Declaration" Malcolm Cohen's YES comment for F90/000096: Sigh, another 12-year-old interp with no edits. Is the answer really not good enough? The suggested reference to 2.5.3 is unhelpful, because it does not answer the user's question, viz What does it mean ... to "declare" something? If we are going to cite 2.5.3 to answer this question we are going to have to come up with an edit to 2.5.3 so that it actually *does* define the term "declaration" in not-so-completely-waffly words. So I think the existing answer, which does actually try to answer the question, is better. Richard Maine's NO vote for f90/000096: The interp is explicitly about f90. There is no mention of whether it still applies to f2003. John Reid's NO vote for F90/000096: I think the answer should be While it is true that there is no formal definition with the term 'Declaration' in bold, 2.5.3 contains the text 'The term declaration refers to the specification of attributes for various program entities. Often this involves specifying the data type of a named data object or specifying the shape of a named array object.' Result: Work on F95 interp F90/000096 is declared done. F95 interp F90/000096 passes WG5 ballot with no change. ...................................................................... F90/000140 TARGET attribute for a derived-type object with a pointer component Richard Maine's NO vote for f90/000140: The interp is explicitly about f90 and f95. Furthermore, the answer is incorrect for f2003. It is no longer true that "The constraints that follow a syntax rule, or a set of syntax rules, are syntactic constraints and apply only to the syntax rules they immediately follow." Constraints include specific indication of what syntax rule(s) they apply to; it is not always the rules that they immediately follow. Result: F95 interp F90/000140 passes WG5 ballot with no change. ...................................................................... F90/000180 Unambiguous generic references Malcolm Cohen's YES comment for F90/000180: The reference in the answer should be noted as being to the F95 document. I utterly reject the notion that the reference needs to be to the F90 document. As to "rewriting the whole thing to F95", I think it already is ok. All the references I checked made Fortran 95 sense. Rob James' NO vote for F90/000180: The explanation given in the answer does not apply to Fortran 2003. Richard Maine's NO vote for f90/000180: The citations are clearly not to f2003. There is no mention of what they are to or of whether they still apply to f2003. John Reid's NO vote for F90/000180: Since the question is phrased in Fortran 90 terms, the answer should be, too. The words are in 14.1.2.3 of Fortran 90. Alternatively, everything could be phrased in Fortran 95 terms. Result: F95 interp F90/000180 passes WG5 ballot but add "in Fortran 95" after the page and line reference in the ANSWER. ...................................................................... F90/000206 Collating sequence inconsistencies Richard Maine's NO vote for f90/000206: The citations are explicitly to the f95 cd (not even to the f95 standard). There is no mention of whether they still apply to f2003 (or even to the published f95). Result: F95 interp F90/000206 passes WG5 ballot but remove the "CD" in the page and line reference before QUESTION 1. ...................................................................... F90/000207 Integer bit-model inconsistency Malcolm Cohen's YES comment for F90/000207: The edit needs to be applied to F2003; the sentence to be removed is the last sentence of 13.3 (04-007:[295:5-6]). Rob James' YES comment for F90/000207: The edit should be done at [293:5-6] of Fortran 2003. Richard Maine's NO vote for f90/000207: The citations are explicitly to the f90. I suppose that the edit must also be - it certainly isn't for f2003. There is no mention of whether they still apply to f2003. David Muxworthy's YES comment for F90/000207: The edits should also be applied to F03 at 293:5-6 John Reid's NO vote for F90/000207: The edit should also be applied at [293:5-6] of N1601. Result: F95 interp F90/000207 passes WG5 ballot with no change. The same edit will be made to Fortran 2003 as part of N1620. ...................................................................... F90/000208 nonadvancing output followed by list directed output Richard Maine's NO vote for f90/000208: The interp references sections that do not exist in f2003. There is no indication that these might be references to f95 or f90 and, if so, whether they still apply to f2003. Result: F95 interp F90/000208 passes WG5 ballot with no change. ...................................................................... JP-24 The bnf term shared-term-do-construct Malcolm Cohen's YES comment for JP-24 The edit has already been applied to F2003, in constraint C827 at 04-007:[166:6-7]. Rob James' NO vote for JP-24: No edit is necessary for Fortran 2003. Richard Maine's NO vote for JP-24: The citations are not to f2003. Only from a parenthetical comment can one deduce that they refer to f95. There is no indication of whether they still apply to f2003. The edit is clearly not an f2003 edit. David Muxworthy's YES comment for JP-24: The proposed edits are already in F03 (at 166:6-7) so defeat of this interpretation would be unfortunate (also true of 000103). John Reid's NO vote for JP-24: It should be stated that the edit has already been incorporated in N1601. Result: F95 interp JP-24 passes WG5 ballot with no change. ...................................................................... F03/0002 Component value for pointer components Malcolm Cohen's YES comment for F03/0002: I do not see what is reprehensible in noting that a future revision might consider clarifying the words. After all, someone was confused by the existing words... 16.4.2 is about "pointer association" in general, but it was obviously not clear (to the editor of the standard!) that it gave an adequate definition of the "pointer association" of an object. John Reid's YES comment for F03/0002: I would like to see the final paragraph of the DISCUSSION deleted. I think there is enough on this in 16.4.2. Alternatively, change 'could be' to 'is'. Result: F03/0002 passes WG5 ballot but change "It could be recommended" to "It is recommended" in the DISCUSSION. ...................................................................... F03/0003 Referencing deferred bindings Malcolm Cohen's NO vote for F03/0003: The edit is faulty - this is not compile-time checkable. The status of this interp should be "Erratum", and the edit should note that *IT* is subsumed by F03/0004. Rob James' NO comment for F03/0003: This cannot be diagnosed by the compiler in general, so it should not be a constraint. This constraint would require a run-time check. David Muxworthy's YES comment for F03/0003, 0004 & 0016: The three items each propose a new constraint C1224a. Presumably that for 0003 is overridden by 0004 but it is not clear, if they pass, whether those for 0004 and 0016 should be combined or remain separate. (Later) To clarify my vote: I had assumed that in N1612, items 000004 to 000104 and JP-24 were F95 interpretations. Of these 16, ten result in no edits, one already includes suggested edits to F03, two could (should?) have corresponding edits applied to F03, two have had their edits already incorporated in F03 and one (000030) relates to text presented differently in F03. Of the nine F90 interpretations, only one results in an edit and this could be applied to F03 if the interpretation is approved. John Reid's NO vote for F03/0003: I do not understand what 'subsumed by F03/0004' means. The edit for F03/0004 covers this interpretation too and is simpler and therefore preferable. I think it should be used here, too. Stan Whitlock's NO vote on F03/0003: The edit is not correct - this is not compile-time checkable. Result: F03/0003 does not pass WG5 ballot and is returned to J3 for further processing. The edit, not the interp, is sumsumed by F03/0004. ...................................................................... F03/0004 Type-bound procedures and undefined association status Malcolm Cohen's NO vote for F03/0004 The edit is faulty - this is not compile-time checkable. Rob James' NO comment for F03/0004: This cannot be diagnosed by the compiler in general, so it should not be a constraint. This constraint would require a run-time check. David Muxworthy's YES comment for F03/0003, 0004 & 0016 above John Reid's NO vote for F03/0004: The edit should not be a constraint since it is not a static restriction. Stan Whitlock's NO vote on F03/0004: The edit is not correct - this is not compile-time checkable. Result: F03/0004 does not pass WG5 ballot and is returned to J3 for further processing. ...................................................................... F03/0016 Invoking type-bound procedures via array objects David Muxworthy's YES comment for F03/0003, 0004 & 0016 above Result: F03/0016 passes WG5 ballot with no change. The edit in F03/0016 is independent of the edit in F03/0004. ......................................................................