J3/00-143r2 JOR Responses to Proposed Edits in 00-103r1 Chapters 1, 2, 3 To: J3 From: Craig Dedo Subject: JOR Responses to Proposed Edits in 00-103r1 - Chapters 1, 2, 3 Date: March 1, 2000 JOR has considered the editorial changes proposed in paper 00-103r1. Following are the responses that JOR is recommending that J3 adopt. These responses are limited to the editorial changes proposed for the Introduction and Chapters 1, 2, and 3. There are 4 categories of action: Deferred JOR decided to defer any recommendation until a future meeting. Yes JOR decided to accept the proposed change and recommends that J3 accept it. No JOR decided to decline the proposed change and recommends that J3 decline it. Not JOR JOR decided that this proposed change does not belong in the jurisdiction of JOR. [Everywhere]The preference to use syntax terms instead of descriptive names begs for a way to get their definitions into the index. I don't think it's necessary to index every appearance in every syntax rule. Indexing the left-hand-sides would be enough. JOR Response: Deferred. The introductory sections need to be rewritten. [Somewhere]There is no normative definition of entity. JOR Response: Deferred. The introductory sections need to be rewritten. [xv:11-12]Section 4 is not limited as described here: There is some material in 4.2 about specifying the type parameters of objects. JOR Response: Deferred. The introductory sections need to be rewritten. [xv:17-22]A brief discussion of features in the various sections is not out-of-place in the Organization part of the Introduction. Is the objection to their being identified as new in Fortran 2000? If so, the "new in Fortran 95" phrase at [xv:34] is (was) also inappropriate. JOR Response: Deferred. The introductory sections need to be rewritten. [4:17-19]Was the behavior of SIGN for negative real zero changed between Fortran 77 and Fortran 90? I thought it was later. JOR Response: Deferred. The introductory sections need to be rewritten. [7:3-5]This looks at first like two citations for ISO/IEC-646:1991. Combine into one paragraph, and replace "ISO/IEC-646:1991 (International reference Version)" by "This". Otherwise, at least either capitalize "reference" or don't capitalize "Version." JOR Response: Yes. But only delete the blank lines between lines 3 and 4 and again between lines 6 and 7. [12:39]This definition confuses rather than claries the definition of host scoping unit at [12:7]. Replace "called the host" by "is the host scoping unit". JOR Response: Yes. [12:42]This definition confuses rather than claries the definition of host scoping unit at [12:7]. Replace "called the host" by "is the host scoping unit". JOR Response: Yes. [13:2]The phrase "within the scoping units of the host" is confusing and incorrect. An internal procedure might be accessible within a derived type denition, but that's kind of useless. An internal procedure is not available within an interface body. Replace "scoping units of the host" by "host scoping unit." JOR Response: Yes. [13:5]Add "for derived-type input/output or" after "invoked." JOR Response: Yes. [13:28-30]Delete "All statements ... module." It is too arcane for the superficial level of section 2, and duplicates material in sections 11.3 and 11.4. JOR Response: Yes. [13:32]What is a "subclause?" Replace "of subclause" by "in". JOR Response: No. The original language was a compromise between our Editor and ISO. If we make the change, the language becomes ambiguous. [2.3.3]Do we want to call end construct statements, e.g. end if, "END statements" JOR Response: No. [2.4.3.1]Should exponent and fraction be called subobjects? JOR Response: No. [16:41]Replace "or redefined" by ", redefined, or undefined." JOR Response: Yes. [17:18 ]Replace "and rank" by "rank, and attributes" (to account for ALLOCATABLE or POINTER attributes of the result). JOR Response: No. [17:38 ]Replace "and an allocatable array" by "an allocatable array, and an array that is a structure component if any of its bounds are declared by using nonkind type parameters." JOR Response: Yes. Instead of the recommended edit, JOR recommends the following edit: [17:37-38] Replace "also. ... allocatable array." with "or may vary during execution." [18:28]Replace "two" by "four" if the change suggested for [18:37+] below is accepted. JOR Response: Yes. [18:37+]Add new paragraphs after note 2.6: "A type parameter keyword may be used in a derived type specifier (4.5.5) to indicate the type parameter for which a value is specified." "A component name keyword may be used in a structure constructor (4.5.6) to indicate the component for which a value is specified." "Note 2.6+ Type parameter keywords and component name keywords can make structure constructors more readable and allow type parameters or structure components to be specified in any order." JOR Response: Yes. Add the two sentences at [18:34+]. Add the text of the note to the existing note 2.6 at [18:37+]. Organize the four (4) definitions of the various kinds of keywords to be a numbered list, with the items numbered (1) through (4). Rewrite the first two sentences of [18:28-29] to read as follows: "The term keyword is used in four ways in this standard: (1) A statement keyword is a word that is part of the syntax of a statement." [19:2]Are RECURSIVE, PURE and ELEMENTAL attributes? Maybe "or attributes" should be "attributes or other properties." JOR Response: No. These procedure characteristics are not attributes. [19:15-16]Should invocation of a procedure by derived-type input/output be in the list? JOR Response: Deferred. [19:29]Add ", modules" after "procedures." JOR Response: Yes. [19:31]Add a new sentence: "Intrinsic modules may be accessed by use association." JOR Response: Yes. [23:25-26]The statement "A lower-case letter is equivalent to the corresponding upper-case letter in program units except in a character context" duels with exceptions for keywords in input/output statements. Those should be mentioned here, too. JOR Response: No. This edit is unnecessary. The normative text of chapter 9 already requires that the character values for I/O keywords be case insensitive. J3 rejected this proposed edit when it passed the edits for Lower Case and Mixed Case Syntax Elements. [27:12-15]This paragraph is self-contradictory. Something like the following would be more self-consistent: "In free source form there are no restrictions on where a statement (or portion of a statement) may appear within a line. A line may contain zero characters. If a line consists entirely of characters of default kind (4.4.4), it may contain at most 132 characters. If a line contains a character that is not of default kind, the maximum number of characters allowed on the line is processor dependent." Should we add ", and not greater than 132" at the end? JOR Response: Yes. Allow the main part of the edit. We do not need to add the language, "and not greater than 132 at the end." [28:3-10]Should TYPE ALIAS be in the list? JOR Response: No. Cross-check section 4.6, [57:35]. [28:13-18]Belongs at [30:6+]. JOR Response: Yes. Move the first sentence of note 3.4 into a separate note at this location and write it in the regular font. Move the rest of note 3.4 into a separate note somewhere in section 3.4. [29:29-30]Should "in character position 6" be "before character position 7?" JOR Response: No. [30:19-31]Suppose I have a file A that consists of two lines, say call s and INCLUDE 'B'. Is it OK if the file B consists of call s? Doesn't this "result in inclusion of the same source text?" JOR Response: No. A programmer is not including "the same source text" if two identical copies of text come from two different sources. The restriction is only intended to prevent circular INCLUDE references. [End of J3 / 00-143r2]