From hirchert@atmos.uiuc.edu Sun Aug 6 22:37:53 2000 Received: from uiatma.atmos.uiuc.edu (uiatma.atmos.uiuc.edu [128.174.80.9]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id WAA50833 for ; Sun, 6 Aug 2000 22:37:52 +0200 (CEST) (envelope-from hirchert@atmos.uiuc.edu) Received: from hirchert.atmos.uiuc.edu (hirchert.atmos.uiuc.edu [128.174.80.212]) by uiatma.atmos.uiuc.edu (8.9.3/8.9.3) with ESMTP id UAA22164 for ; Sun, 6 Aug 2000 20:37:51 GMT Message-Id: <4.3.1.2.20000806152930.00b30e10@uiatma.atmos.uiuc.edu> X-Sender: hirchert@uiatma.atmos.uiuc.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sun, 06 Aug 2000 15:37:50 -0500 To: SC22WG5@dkuug.dk From: Kurt W Hirchert Subject: Re: (SC22WG5.1851) WG5 letter ballot on Fortran 95 interpretations In-Reply-To: <200006301432.QAA12998@dkuug.dk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed >Yes No Number Title > >-C- --- 000067 Writing zeros I find this "change" acceptable because I believe this is what the f90 committee intended. >-C- --- 000068 Asterisks as I/O units I'm voting yes because I believe the edit to be correct, but I believe the answers and discussion can be misconstrued. In my experience, there are two ways that, for example, the input asterisk unit and unit 5 could come to be "the same thing": 1) They could be the same unit (as clarified by the edit). In this case, closing unit 5 affects the input asterisk because they are the same unit and thus the same connection. 2) They could be separate units connected (as a processor extension) to the same file. (A standard-conforming program is not allowed to connect two units to the same file, but I believe that a processor is allowed to do so as an extension, and that as long as a program uses only one or the other of those units, it is not using the extension and thus not nonconforming on that basis.) In this case, I would expect closing unit 5 to have no effect on the asterisk unit because they are different units and have independent connections to files. The interpretation focuses primarily on case 1 (because case 2 involves an extension), but, in my experience, case 2 is the more common implementation, so there is a potential for misunderstanding. >-X- --- 000069 What is a numeric character? > >-X- --- 000070 Asymmetry between constant specification and > initialization expressions > >--- -X- 000071 Character array constructors I oppose this item because I feel that it fails to adequately answer the question asked and that it raises at least as many questions as it answers, possibly because one of the specific answers it gives it wrong. Although never explicitly stated as a question, the original inquiry clearly is asking about how the rules on type parameters in array constructors are to be applied to zero-trip implied DOs. The answers supplied only minimally address the application of the existing rules, focusing instead on the imposition of new rules. The answer that I believe may is incorrect is the answer to the third explicit question. The reasoning there shows that the character length of the array constructor cannot be something other than 5, but it does not show how this constructor meets the requirement "If the expressions are of type character, each expression in the shall have the same character length parameter." I suggest that it does not. Consider the following sequence of transformations to the program in the third specific question: - Change "f = 2*i + 5" to "f = 2*i + 4". - Change "f = 2*i + 4" to "f = 0*i + 4". - Change "f = 0*i + 4" to "f = 4". - Change sub so it uses a variable f that has been set to 4, rather than invoking the function f that returns 4. - Change the variable f to a constant 4. Given the statement that "There is no exclusion for s that contribute no elements to the value of the array constructor: thus s that are inside zero-trip implied DO loops still contribute their "type" information," I believe that the final result of this transformation clearly does not conform, and I see no obvious point in the transformations at which it would have switched from conforming to nonconforming, so I conclude that the original program also did not conform, contrary to the statement in the answer. For this reason I vote against this item. I also believe that the new rules imposed by this item are ill-chosen. If that were all that was wrong with this item, it is likely that I would act as I have on several other items in this ballot and comment without voting no, but since I believe this item needs further work, I would suggest that the rules also be subject to further consideration. I offer three objections to the rules proposed: 1. When imposing rules on an aspect of the language that has nominally been unrestricted until now, I would expect the new rules to impose only as much restriction as was absolutely necessary. Instead, these rules are only minimally permissive. Such an approach may be appropriate when introducing new features to the language, but I find it inappropriate when modifying an already published standard. 2. It is desirable if the rules reflect some inner consistency. The basis for these rules appears to be those expressions whose length can be determined without depending on any variables to be defined, but it omits the concatenation of strings whose length is known in this way. (I think this underlying rationale is too restrictive, but the rules should at least allow that which fits the rationale.) 3. It may be acceptable to restrict the way in which zero-length arrays are constructed, provided a minimum level of functionality remains available. In this case, it is desirable to be able to construct zero-length character arrays of arbitrary character length (determined at execution). The proposed rules do not provide this functionality, allowing only construction of constant lengths or lengths that match the length of accessible character variables. >-X- --- 000072 Resolving generic procedure references > >-X- --- 000076 INTENT(IN) dummy arguments and implied DO loops > >-X- --- 000077 INTENT(IN) dummy arguments and NULLIFY > >-C- --- 000079 Pointer Assignment and Allocatable Arrays My preference would have been to allow such pointer assignments, specifying that this makes the pointer null, but I can accept this. >-X- --- 000080 Host association and the EXTERNAL attribute > >-X- --- 000082 Usage of BOZ literal constants > >-C- --- 000083 Scope of array-constructor implied-DO variable I vote for this item reluctantly. I believe it to be an incorrect interpretation of the existing text in the standard. I find implausible the suggestion that the author of this section substituted the undefined phrase "implied-DO list" for the _shorter_ defined phrase "implied DO". It seems much more likely to have been a substitution for a longer phrase, probably one containing the word "list". An obvious candidate is " in the implied-DO". The discussion dismisses this alternative with an inelegant phrasing, but I feel that unfairly ignores the elegance of having the scope of the implied-DO variable extend to those portions of the implied DO where it can legally be used and not to those portions where it cannot. Having said all this, the difference between the correct interpretation and the incorrect interpretation offered here is minor. Programs that exploit the difference between them are obfuscated and likely to run into implementation errors. I am annoyed by this gratuitous language change that serves only to reduce the set of conforming programs with no corresponding gain, and I would have preferred a clarification that reflected the correct interpretation, but my objection is largely aesthetic, so I comment without a negative vote. >-X- --- 000084 Events that cause variables to be defined > >-X- --- F90/000100 ASSOCIATED intrinsic and zero-sized objects > >-X- --- F90/000179 DO variable with POINTER attribute > >-X- --- F90/000185 What is the allocation status of an array > after an allocation failure? > >-X- --- F90/000194 Statements between SELECT CASE and CASE -- Kurt W Hirchert hirchert@atmos.uiuc.edu UIUC Department of Atmospheric Sciences +1-217-265-0327