From owner-sc22wg5 Mon Jul 23 17:58:14 2001 Received: from nameserv.rl.ac.uk (nameserv.rl.ac.uk [130.246.135.129]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id RAA98451 for ; Mon, 23 Jul 2001 17:58:13 +0200 (CEST) (envelope-from jkr@jkr.cc.rl.ac.uk) Received: from jkr.cc.rl.ac.uk (jkr.cc.rl.ac.uk [130.246.8.20]) by nameserv.rl.ac.uk (8.8.8/8.8.8) with ESMTP id QAA27637 for ; Mon, 23 Jul 2001 16:58:13 +0100 Received: (from jkr@localhost) by jkr.cc.rl.ac.uk (8.8.8+Sun/8.8.8) id RAA13671 for SC22WG5@dkuug.dk; Mon, 23 Jul 2001 17:00:24 +0100 (BST) Date: Mon, 23 Jul 2001 17:00:24 +0100 (BST) From: John Reid Message-Id: <200107231600.RAA13671@jkr.cc.rl.ac.uk> To: SC22WG5@dkuug.dk Subject: Provisional result of WG5 ballot MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Dear WG5 members, Here is the provisional result of the WG5 ballot on interpretations. If you voted, please check that I have recorded your vote correctly and let me know of any errors by Wednesday. Cheers, John Reid. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ISO/IEC JTC1/SC22/WG5-N1435 Results of the ballot on interpretations John Reid, 23 July 2001 2 10 11 12 18 19 20 21 22 24 25 28 Cohen y y y y y y y y y y y y Dedo y y y y y y y y y y y y Hendrickson y y y y y y y y y y y y Hirchert yc y y y yc y y n y y yc y Kruyt y y y y y y y y y y y y Long y y y y y y y y y y y y Mahonen y y y y y y y y y y y y Maine y y y y y y y y y y y y Martin y y y y y y y y y y y y Meadows y y y y y y y y y y y y Morgan y y y y y y y y y y y y Muxworthy y y y y y y y y y y y y Nagle y y y y y y y y y y y y North y y y y y y y y y y y y Reid yc y y y y y y y y y y y Ross y y y y y y y y y y y y Schoenauer y y y y y y y y y y y y Snyder y y y y y y y y y y y y Whitlock y y y y y y y y y y y y JP 29 81 85 87 88 89 90 91 92 93 06 Cohen y y y y y y y y y y y Dedo y y y y y y y y y y y Hendrickson y y y y y y y y y y y Hirchert y n y yc y y y n y y y Kruyt y y y y y y n y y y y Long y y y n y y y y n y y Mahonen y y y y y y y y y y y Maine y y y yc y y y y y y y Martin y y y y y y y y y y y Meadows y y y y y y y y y y y Morgan y y y y y y y y y y y Muxworthy y y y y y y y y y y y Nagle y y y y y y y y y y y North y y y y y y y y y y y Reid y y y y y y y y y y y Ross y y y y y y y y y y y Schoenauer y y y y y y y y y y y Snyder y y y y y y n y y y y Whitlock y y y y y y y y y y y Comments 2 Reid Somehow, an error has crept into the first line of the question, which should read Consider the following PRINT statement form: PRINT"(I5)",5 2 Hirchert Part of the text of the question is missing. 18 Hirchert I am uncomfortable with some of the reasoning behind answer 2, but I have no objection to the final result. 21 Hirchert Although I can understand why vendors would wish to implement it that way, I find it ludicrous to assert that ".NE." is "identical" to "/=". I do not believe it was our intent to allow this case, and do not see it to be beneficial to the programmer to make such an allowance. If we are insistent on making this _change_ in the requirements of the standard, the edit does appear to be acceptably constructed. 25 Hirchert I would have preferred an interpretation in which 2*.TRUE. would be equivalent to .TRUE. .TRUE. and acceptable as input to a LOGICAL variable followed by a CHARACTER variable. 81 Hirchert I agree that a change is necessary, but I still see no justification for totally ignoring pointer components. In my opinion, a more appropriate change would be to require the pointer components not to have an undefined pointer association status. 87 Maine I'm slightly concerned here about IEEE compatability. Does IEEE say anything about this case? (I don't actually know). If it does, then we'd at least want to allow IEEE compatability. True, a processor could always give the IEEE result as an "extension". But if the intent is to allow this, it might be better to do something along the lines of the words in the 4th para of 7.1.7, which says that operations are prohibited "if the result is not defined by the arithmetic used by the processor". This is perhaps more a question for f2k that for f9x. But I'd hate to pass this as an f9x interp and then see it used as a reason why we couldn't allow the IEEE behavior in f2k. On the other hand, if IEEE doesn't define a result for these operations, then my concern is moot. 87 Long The proposed changes represent a change to the standard that is too significant for an interp. Also, the discussion appears to be focused on INTEGER arguments, though REAL arguments to MOD and MODULO are also supported. Division by zero is supported for REAL values on some architectures. It would seem that the current "processor dependent" text would be preferred in that case. 87 Hirchert I believe the text in question was introduced in the effort to make Fortran less incompatible with the computational model of IEEE arithmetic. I believe was wanted to do was to allow the possibility that programs running on IEEE machines would still be standard conforming if MOD or MODULO were invoked with a P argument of zero (producing a NaN result?). However, I do not believe it was our intent to force non-IEEE machines to accept this implicit division by zero. Thus, I believe the existing text to be defective. The proposed new text goes too far the other way, but I believe that it gets us closer to where we want to be than the existing text. (I.e., the new text allows processors to be built the ways we wanted to allow, while the existing text does not. The deficiency in the proposed text is in labeling some programs to be non-conforming that we intended to be conforming, but the programs so labeled are ones whose portability is questionable, so the effect of this mislabeling is minimal.) 90 Snyder I prefer any of the answers in J3 paper 01-138 (not 01-138r1). These answers amount to allowing properties deduced from a declaration in the same entity-decl to be used in the initialization. The argument that appears to have carried the day is that any of these answers cause work for vendors. But several vendors already interpret the standard according the answers in 01-138, so interpreting the standard according to 01-138r1 makes work for those vendors. Given that either interpretation makes work for somebody, I prefer the one that is more useful. 90 Kruyt I agree with Van Snyder's comment 91 Hirchert I agree with the intent of this interpretation, but I am concerned that the edit is inadequate. My specific concern is that by addressing host association in this aspect of PRESENT, we may have implicitly disallowed other useful host association. My particular concern was whether an internal procedure can use PRESENT on one of its host's dummy arguments. If someone can convince me that this new definition of present raises no questions about such uses of PRESENT, I will withdraw my objection. Alternatively, I would restructure the recursion in the definition: "A dummy argument or entity host-associated with a dummy argument is not <> if the dummy argument is (1) not associated with an actual argument, or (2) is associated with an actual argument that is not present. Otherwise, it is present." This makes it clear that the concept of being present applies to entities host-associated with a dummy argument, so the PRESENT intrinsic function may be applied to them. 92 Long The proposed change represents a significant improvement and should be made in the F2K standard. However, the change introduces too great of an incompatibility with the current standard to be made through an interp to F95. ........................................................... Items 2 10 11 12 18 19 20 22 24 25 28 29 85 88 89 93 PJ/06 passed unanimously. A correction needs to be made to the question in item 2. Items 21 81 87 90 91 92 collected one or two NO votes. WG5 will decide at its London meeting whether these items should be returned to J3 for further consideration.