From owner-sc22wg5@open-std.org Wed Jan 12 13:38:49 2005 Return-Path: X-Original-To: sc22wg5-domo1 Delivered-To: sc22wg5-domo1@open-std.org Received: by open-std.org (Postfix, from userid 521) id 1B1FF149E7; Wed, 12 Jan 2005 13:38:49 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from dkuug.dk (ptah.dkuug.dk [195.215.30.66]) by open-std.org (Postfix) with ESMTP id EE68811F16 for ; Wed, 12 Jan 2005 13:38:46 +0100 (CET) Received: from balin.rl.ac.uk (balin.rl.ac.uk [130.246.135.155]) by dkuug.dk (8.12.10/8.9.2) with ESMTP id j0CCZrwE063379 for ; Wed, 12 Jan 2005 13:35:55 +0100 (CET) (envelope-from j.k.reid@rl.ac.uk) X-RAL-MFrom: X-RAL-Connect: Received: from jkr.cse.rl.ac.uk (jkr.cse.rl.ac.uk [130.246.9.202]) by balin.rl.ac.uk (8.12.8/8.12.8) with ESMTP id j0CCc8W3005982; Wed, 12 Jan 2005 12:38:09 GMT Received: from rl.ac.uk (localhost.localdomain [127.0.0.1]) by jkr.cse.rl.ac.uk (8.12.10/8.12.8) with ESMTP id j0CCdCIc028497; Wed, 12 Jan 2005 12:39:12 GMT Message-ID: <41E51A70.7080601@rl.ac.uk> Date: Wed, 12 Jan 2005 12:39:12 +0000 From: John Reid Reply-To: j.k.reid@rl.ac.uk Organization: Rutherford Appleton Laboratory User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.3) Gecko/20041005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: WG5 Subject: Malcolm Cohen's WG5 interpretation ballot (resent) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.39 X-Spam-Score: 0 () Sender: owner-sc22wg5@open-std.org Precedence: bulk I am very sorry - the copy of Malcolm vote that I sent had extra lines added. Please discard it and use this one. Sorry, John. -- Start of included mail From: Malcolm Cohen Subject: WG5 interpretation ballot To: sc22wg5@dkuug.dk Date: Wed, 12 Jan 2005 16:24:13 +0900 (JST) Hi folks, This is my vote on the WG5 interps ballot. 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. Yes No Number Title -C- --- 000004 Value returned by MAXVAL/MINVAL -Y- --- 000006 Character length specification of a function result -Y- --- 000008 Optional arguments to MAX/MIN -Y- --- 000017 Characteristics of an array function result -Y- --- 000023 Termination of the previous record by a WRITE statement -C- --- 000030 Ordering requirements on definition of specification functions -C- --- 000031 Association of pointer function result with INTENT(OUT) dummy argument (subsumed by 000074) -Y- --- 000068 Asterisks as I/O units -C- --- 000074 TARGET dummy arguments and POINTER expressions -C- --- 000078 Resolving generic procedure references -C- --- 000096 End-of-record and PAD --- -N- 000098 Are dummy functions returning assumed-length character legal? (duplicate of 000006) --- -N- 000102 mask-expr evaluated only once -C- --- 000103 Derived type name DOUBLEPRECISION -Y- --- 000104 Representation method of result of REAL -C- --- F90/000049 Characteristics of function results -Y- --- F90/000070 Characteristics specified by interface bodies -C- --- F90/000096 Definition of "Declaration" -Y- --- F90/000140 TARGET attribute for a derived-type object with a pointer component -C- --- F90/000180 Unambiguous generic references -Y- --- F90/000206 Collating sequence inconsistencies -C- --- F90/000207 Integer bit-model inconsistency -Y- --- F90/000208 nonadvancing output followed by list directed output -Y- --- F90/000210 nonadvancing write followed by list directed write -C- --- JP-24 The bnf term shared-term-do-construct -Y- --- F03/0001 Generic type-bound procedures -C- --- F03/0002 Component value for pointer components --- -N- F03/0003 Referencing deferred bindings {subsumed by F03/0004} --- -N- F03/0004 Type-bound procedures and undefined association status -Y- --- F03/0005 Argument association and the TARGET attribute -Y- --- F03/0006 Intrinsic assignment and allocatable components -Y- --- F03/0007 Finalization of structure constructors in specifications -Y- --- F03/0009 VALUE attribute for passed-object dummy arguments -Y- --- F03/0010 Unlimited polymorphic pointer/allocatable dummy arguments -Y- --- F03/0011 Allocating objects of abstract types -Y- --- F03/0013 VALUE attribute for polymorphic dummy arguments -Y- --- F03/0014 Automatic arrays in interface bodies -Y- --- F03/0015 TARGET attribute for associate names -Y- --- F03/0016 Invoking type-bound procedures via array objects Comments: F95/000004 The last paragraph should read "Fortran 2003 uses similar wording in MAXVAL and MINVAL to that in Fortran 95." 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.} 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. 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. F95/000078 The edit should be applied to F2003, at 04-007:[278:5+] (immediately before 12.4.4.2). 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!). 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. 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.) F95/000103 The edit has already been applied to F2003. 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. 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. 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. 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]). JP-24 The edit has already been applied to F2003, in constraint C827 at 04-007:[166:6-7]. 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. 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. F03/0004 The edit is faulty - this is not compile-time checkable. Cheers, -- ...........................Malcolm Cohen, Nihon NAG, Tokyo, Japan. (malcolm@nag-j.co.jp) -- End of included mail.