From Miles.Ellis@etrc.ox.ac.uk Wed Apr 9 14:01:08 1997 Received: from oxmail4.ox.ac.uk ([163.1.2.33]) by dkuug.dk (8.6.12/8.6.12) with SMTP id OAA14059 for ; Wed, 9 Apr 1997 14:00:54 +0200 Received: from ermine.ox.ac.uk by oxmail4 with SMTP (PP) with ESMTP; Wed, 9 Apr 1997 13:00:43 +0100 Received: from [163.1.85.1] (com1.etrc.ox.ac.uk [163.1.85.1]) by ermine.ox.ac.uk (1.1/8.8.3) with ESMTP id NAA22581 for ; Wed, 9 Apr 1997 13:00:41 +0100 (BST) X-Sender: mellis@ermine.ox.ac.uk Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 9 Apr 1997 13:01:11 +0100 To: sc22wg5 From: Miles Ellis Subject: Approval Ballot for editorial changes resulting from F95 DIS ballot As you all know, the DIS ballot passed by 22 votes to 1. The NO vote was from France and related to the incorrect French translation of the title provided by ITTF! It will change to YES when a correct translation is incorporated. In the course of establishing this translation it became apparent that the direct French translation of the preferred English title is not acceptable, and so we need to agree on one of two alternative English titles - "Primary Language" or "Base language"; the French title will be "Langage de base." This is discussed further below. France, Japan and the UK submitted editorial comments with their ballots, and I have discussed these with an ad-hoc editorial committee consisting of Richard Maine, David Muxworthy, John Reid, Jerry Wagener, Stan Whitlock and myself. At the end of this message is a list of the complete comments received, and the action proposed. I intend to have a 30-day ballot on the acceptability of these responses and to then submit the DIS, modified as indicated to ITTF for publication, together with a Disposition of Comments document containing the responses shown below. If there are any significant objections or alternative suggestions to the responses proposed then these will be discussed by the ad hoc editorial group and, if necessary, a further 30-day ballot held on the revised responses. Following the ballot comments and proposed responses, I have also included some of the more detailed reasons expressed by members of the ad hoc group as background information to the thinking that led to the proposed responses. Miles ------------------------------ WG5 Ballot ---------------------------------- Please return this ballot to the Convenor NO LATER THAN 30TH APRIL 1997. __________ 1. I agree with the proposed responses to the comments | | | submitted in the ballot on DIS 1539-1:1997 (Fortran 95) | YES | NO | |_____|____| If NO, give alternative response(s) proposed: 2. I wish the English Part Title to be (indicate one only!) ___ (a) Primary Language | | |___| (b) Base Language | | |___| (signed) ................................ (date) .................... ----------------------------- End of WG5 Ballot ---------------------------- -------------- DIS Ballot Comments and Proposed Responses ------------------ Before detailing the comments I should refer to the ITTF-supplied pages which were the cause of one French and two Japanese comments. The first page reads as follows: Information technology - Programming languages - FORTRAN - Part 1: Form specification (Revision of OSO/IEC 1539:1991) Technologies de l'information - Langages de programmation - FORTRAN - Partie 1: Spe'cifications formelles ICS 35.060 Descriptors: data processing, computer software, artificial languages, programming languages, advanced language, FORTRAN. [plus some standard stuff that appears on all such documents] The second page reads: Draft International Standard ISO/IEC DIS 1539-1 ISO/IEC JTC1 Secretariat: ANSI Information technology - Programing languages, their environments and system software interfaces - Fortran, Part 1 The rest of the DIS is what we (i.e. Rich Maine) provided. There are two obvious errors in the first page: 1. The name of the language is Fortran,not FORTRAN 2. Part 1: Form specification is clearly wrong. It presumably was meant to be "formal specification", but even that would have been incorrect. We always refer to it simply as Part 1; however other multi-part standards always have part names, and ITTF added the (incorrect) English and French part name before sending it out for its DIS ballot. The ad hoc group suggested that the Part name be "Primary Language" on the grounds that Part 2 refers to Part 1 as "the primary language standard", and asked our French colleagues to provide an acceptable French translation. Unfortunately, they have informed me that the direct French translation, "langage primaire" has a pejorative connotation of being "undevelpped", and propose that the French version should be "langage de base". The ballot therefore asks whether the English title should remain as Primary Language, or change to Base language in line with the French title. We should also alter the first paragraph of the Foreword in a corresponding manner. The complete set of comments and proposed responses follows: AFNOR Ballot Comments on ISO/IEC DIS 1539-1 - Fortran, Part 1 SOURCE: AFNOR AFNOR votes NO to ISO/IEC DIS 1539-1 AFNOR will reverse its vote if its comment on the French title is adopted. ITEM 1 Qualifier: Major editorial Reference: Document title Rationale: French title inaccuracy "Specification" should be without an "s" - "formel(les)" is the french equivalent of "formal". Proposed Change: Change the French title for the following: Technologies de l'information - Langages de programmation - FORTRAN - Partie 1 : spe'cification du langage. The proposed new title is choosen after the first line of page xiii, introduction, Standard programming... We also suggest that the English title be: Language Specification. Response: -------- Agreed in principle. However, the English title was also wrong. It should be Information technology - Programming languages - Fortran - Part 1: Primary Language (Revision of ISO/IEC 1539:1991) The French title should be Technologies de l'information - Langages de programmation - Fortran - Partie 1: Langage de base In this connection it is also proposed that the first paragraph of the Foreword be altered to incorporate the part name as follows: "ISO/IEC 1539 is a multi-part International Standard defining the Fortran programming language. This document is Part 1 - Primary Language, ISO/IEC 1539-1:1997. Part 2 is ..... [as before]" ITEM 2 Qualifier: Editorial Reference: P.178 - Note 10.30 Rationale: Should precise the pre-last paragraph of p.177 (where the proposed sentence could also be placed as an alternative) Proposed Change: Add the following precision as first sentence: For integer output, w may be constant (type dependent) or variable (value-dependent). Response: -------- No. If this change were made, similar changes would also need to be made elsewhere in the Standard. The existing note is clear, and the wording has remained largely unchanged since FORTRAN 77. ITEM 3 Qualifier: Editorial Reference: P.212 - two first constraints Rationale: The 2 first constraints should be re-written in order to facilitate distinction between what is general and what is particular of the functions. Proposed Change: Re-write the 2 first constraints as follows: The specification part of a pure subprogram shall specify the intents of all dummy arguments except... In the case of a pure subprogram of type function, all dummy arguments shall have INTENT (IN), except... Response: -------- No. The present wording is clear and unambiguous. The proposed change is an alternative which might have marginal advantages, but the wording proposed creates subtle technical changes and would require further technical work on the DIS. ITEM 4 Qualifier: Editorial Reference: P.213 - Note 12.33 second paragraph Rationale: It is not the place in an International Standard to state that checking is better than flexibility, nor that adherence to the letter of the text rather than to its spirit is an enhancement. This statement seems to support the principle of gratuitous constraints. Proposed Change: Remove the last sentence of the paragraph. Response: -------- Agreed. This change will be made before the document is forwarded for publication. ITEM 5 Qualifier: Editorial Reference: P.215 - last paragraph Proposed Change: Remove the paragraph as it is. Provide a note (12.38) stating something like: The full specifications of intrinsic subroutines are known by the compiler. They may thus have the elemental attribute and be implemented accordingly although they do not verify the given constraints. For instance, in a reference to the elemental intrinsic subroutine MVBITS, the actual arguments to the TO and FROM dummy arguments may be the same variable. However, any other elemental subroutine reference must satisfy the restrictions on subroutine referencing of 12.4.1.6. This note could also be moved to 12.4.1.6, to which it pertains more. Response: -------- No. The paragraph is essential normative text. Its removal would be a substantial technical change, because 12.4.1.6 would then preclude a call being made to MVBITS in this way. ITEM 6 Qualifier: Editorial Reference: P.222 - Note 13.5 Rationale: It is not clear what is meant by "remaining" in this context: "non-elemental" or "different from MVBITS" or "to be described further". We believe that "different from MVBITS" should be preferred. In the present text, it is easier to understand mistakenly (?) one of the two other meanings. Proposed Change: Clarify note 13.5 Response: -------- We agree that some clarification may be desirable. Instead of the proposed text we intend to replace "remaining" by "non-elemental". JAPAN'S COMMENTS ON ISO/IEC DIS 1539-1 The National Body of Japan approves ISO/IEC DIS 1539-1 with the following comments. Item No: JP1 Page: Cover Page (first page) Qualifier: Editorial Proposal: In the title, replace "FORTRAN" with "Fortran". Response: -------- Agreed Item No: JP2 Page: Title Page (second page) Qualifier: Editorial Proposal: In the title, add the part name ", Form Specification" after "Part 1". Response: -------- No. Instead the part name should be "Primary Language", with a corresponding change to the French part name. Item No: JP3 Page: 277 Qualifier: Editorial Proposal: In the fifth line of the subclause "14.1.2.3", replace "for each argument or operand" with "for each operand". Response: -------- Agreed. Item No: JP4 Page: All pages Qualifier: Editorial Proposal: In both the header and footer lines for each page, delete "COMMITTEE DRAFT". Response: -------- Agreed. This would have been done in any case. UK COMMENTS ON ISO/IEC DIS 1539-1 (REV) : PROGRAMMING LANGUAGES : FORTRAN The UK votes approval of the DIS ballot, however, if any changes are made by SC22/WG5 to the Proposed Technical Corrigendum 3 to ISO/IEC 1539:1991 as a result of comments made in the recent SC22 ballot, corresponding changes should also be made to the revision of ISO/IEC 1539:1991. Response: -------- Agreed. The only change made was that referred to in the Japanese comment JP4. -------------- end of DIS Ballot Comments and Proposed Responses ------------- --------------- Additional ad hoc group comments re. responses -------------- AFNOR ITEM 2 ------------ This comment directly relates to f90 interpretation 152. It essentially attempts to clarify the standard so that the answer to interpretation 152 is more obvious. The wording in question comes almost unchanged from Fortran 77. I agree that it would probably have been better to make this point a little more explicit. If this comment had been made earlier in the process, I would recommend doing something with it. However, since the wording has been largely unchanged since f77 and there is an official interpretation request (without edits) making the point explicit, I don't see this as an item important enough to merit slipping in at the last minute. I have several qualms about the exact proposed wording, placement, and simillar editorial details. If the rest of the group/committee feels we should do this, then I'll try to come up with some proposed words that I'd be happy with. But my general feeling is that we shouldn't be trying to do this at this stage. General nature of qualms. 1. No obvious connection with the rest of note 10.30, where it is propoised to be placed. The proposed alternate placement in normative text near the end of page 177 is better. 2. Fails to address the same identical issue on page 182 under namelist output editing. If we do it one place, we should do it both or invite questions about the difference. This is an excellent sample of the kind of inconsistency that is easy to introduce with last-minute edits that do not get as thoroughly reviewed as earlier work. 3. Why does the proposed edit apply only to integer output? I can only speculate that it is because that is the first place that the question occurred to someone. I cannot see, from the point of the standard, why the same thing does not apply to other numeric output. 4. The use of the terms "constant" and "variable" is confusing in that it has nothing to do with constants or variables. 5. The term "type dependent" presumably refers to dependence on the type parameters rather than on the type (since the whole sentence is only about type integer). (Richard Maine) No. I think this turns a clear note into an obscure one and that the paragraph 177:43-44 is itself clear and needs no note. (John Reid) AFNOR ITEM 3 ------------ I don't mind the gist of the comment (be general first, and then more specific), but the phrase "pure subprogram of type function" is bad. ("Type" is used consistently in the standard for something very different.) This wording could be fixed, in my opinion, by deleting "subprogram of type". But then the first constraint reads "...of a pure subprogram..." and the second reads "...of a pure function...". That's switching mental gears and therefore potentially misleading at best; a "subprogram" is a physical entity (a container), where as a procedure is a conceptual (non-physical) thing. Quite possibly, therefore, the suggested version is subtly different technically from the original and therefore would force another ballot. We ought to either not make this change or look at the final wording very carefully. The above discussion on item 3 is a classic example of seemingly innocent wordsmithing causing subtle technical changes. Perhaps we shouldn't be too accommodating with these suggested edits without airing them more fully. (Jerry Wagener) Jerry makes some valid points about the wording details. We could probably wordsmith these out, but again I'm dubious that we should be doing such wordsmithing at this late a stage for somthing that isn't actually wrong. In this case, there is not obvious confusion being corrected or any other concrete gain. (Unlike ITEM 2, where there is a possible confusion). And whereas the general principle of stating the general before the particular is good, I don't see that it really applies well here. As it stands, the DIS has one constraint for functions and another for subroutines. This is at least a plausible organization of these two points. It is also reasonable to try to abstract those things that apply to both subroutines and functions before making the detailed distinctions. But in this particular case, that organization doesn't much help. The general point is that the intent of all the arguments (with longish list of exceptions) must be specified. There is no further specific point for subroutines. For functions, the specific point is that the specifications must all be INTENT(IN). I don't see any real benefit in separating the two statements that 1. The intent must be specified 2. And it must be specified to be IN. It seems at least as simple to just say in a single constraint that the intent must be specified to be IN. Anyway, the point I'm making here is not that the suggested change is necessarily bad. But rather that there are arguments for both forms of presentation in this case. Given that either form is plausible, I'd vote for leaving it alone as is instead of making a change to another form that is perhaps also ok, but not unarguably better. And if we do make the change, we'd better address the issues that Jerry raised or we risk changing it to something that is confusing or even wrong. (Richard Maine) No. The present wording is clear and unambigous. It is consistent with the style of the rest of the section (for example, see the separate subsections 12.5.2.2 and 12.5.2.3). (John Reid) AFNOR ITEM 4 ------------ This one I think I agree with. That particular sentence is probably best omitted. The other material in the paragraph adequately gives the facts. That particular sentence is a bit too personal in referring to the committee. I'm not sure why I let that one through myself, except perhaps that the wording of this note was the subject of a lot of controversy and I perhaps thought it best to take a "hands off" attitude about what passed. I don't recall the details. In any case, regardless of the reasons why the sentence is there, I'd agree with deleting it based on the French comment. I can't see how deleting it would do any harm. (Richard Maine) AFNOR ITEM 5 ------------ This gets into substantial technical issues, not just editorial. The proposal is to delete some normative text and replace it with a note. That particular normative text was the result of extensive debate and wordsmithing. I do not consider it an "editorial" matter to delete this material from the normative text. There are also several wording qualms with the proposed replacement. Considering how much debate it took to get the wording of the existing text acceptable to everyone, I don't relish trying to "wing it" and come up with different wording that still satisfies everyone else and yet also satisfies whatever objection (unspecified) the French had to the existing wording. This is the item that I'm most against. I can't realistically see any reasonable answer to this one except "no" (appropriately worded, of course). I have no substitute wording in mind except to stick with the existing DIS wording. (Richard Maine) No - this is essential normative text. It says that MVBITS may be called in this way. Without the text, 12.4.1.6 would preclude such a call. (John Reid) AFNOR ITEM 6 ------------ I'm confused by the confusion. Nothing in the note mentions MVBITS, so I don't see how it would plausibly be considered to be the referent for "remaining". I would normally presume that "remaining" meant those not described in the imediately preceding sentence (the only other sentence of the note); that is the remaining ones are the non-elemental ones. Since MVBITS happens to be the only elemental intrinsic subroutine, the sentence would be correct with remaining interpreted as "other than MVBITS", but it wouldn't make logical sense (and it would become wrong if another elemental intrinsic subroutine were added). On the other hand, changing "remaining" to "non-elemental" is a pretty innocuous change. That's the change I would propose here as a clarification. I see it as a neutral change, neither better nor worse than the original. If others think it would help clarify the meaning, I have no objection to the change. (Richard Maine) Agree with Richard - change "remaining" to "non-elemental" - it is clearer. (John Reid) ---------- end of additional ad hoc group comments re. responses ------------ Miles Ellis Convenor: ISO/IEC JTC1/SC22/WG5 Email: Miles.Ellis@etrc.ox.ac.uk Phone: +44 1865 270528 Fax: +44 1865 270527