To: J3 J3/21-100 From: Malcolm Cohen Subject: Editor's report for 21-007 Date: 2020-December-18 1. Introduction This is the editor's report for 21-007. This draft includes all of the relevant passed papers from meeting 222, along with the recently-approved draft Corrigendum 1, plus a number of small corrections and improvements suggested by email. I made a lot of changes to fix perceived problems in the papers. Subgroups should check carefully that the changes I made were appropriate. It goes without saying that everyone should check that the changes that do not arise from a passed paper are appropriate. 2. List of papers from meeting 222 20-131 20-145 20-133r3 20-146 20-135r1 20-148r2 20-137r1 20-153r1 20-139 20-156r1 20-140 20-158r3 20-141r1 20-160r3 20-144r2 20-163 3. Papers and comments in order of application 20-140. Done. 20-141r1. Done. COMMENT: I notice that there is a paucity of examples in the clause 18 (C interop) module procedures, unlike the intrinsics and the ieee modules. Maybe that should be improved? 20-139. EXTRA: [347: Middle of table 16.1] Replace SPLIT entries in summary table. [433:23+] DIFFERENT: "When" -> "If" (it's a straightforward condition, not time-dependent); "with a value for POS of" -> "with a value for POS in the range"; comma after LEN(STRING); "STRING(POS:POS) is not a token delimiter present in SET," ->"the value of STRING(POS:POS) is not equal to any character in SET,"; "does not comprise" -> "will not comprise". EXTRA: Delete UTI 002. Delete UTI 003. Delete UTI 004. EXTRA: [434:1-4] In the BACK argument, deleted "If POS does not appear... beginning." as POS now always appears with BACK. EXTRA: [434:6,13,20] Re-typeset examples so they are not new paragraphs; they are part of the single "Examples" paragraph. Also adjusted vertical spacing to improve layout. Done. 20-137r1. DIFFERENT: "may" -> "might" (possibility not permission), twice, "an intrinsic" -> "a reference to an intrinsic" (they are not "in" the intrinsic), "these assignments" -> "these cases" (they are not all assignments per se). Made the last para into a single-item bullet list (and thus part of the previous para). Done. 20-145. Done. 20-146. Done. 20-135r1. REJECTED as is (see the end of the report for resolution). Here are some comments and reasons for rejection as is. COMMENT: Multitudinous wording problems (all fixable and fixed). One should not use words like "introduced", "support", or "agnostic" in the Introduction. As the paper requires drastic revision, further detailed comments on (the many) wording problems and fixes thereof are omitted. (Describing the changes rigorously would be several times larger than the actual resultant text, so not terribly useful). TECHNICAL COMMENT: It is not really acceptable to have three "attributes" for the same thing, viz dimension information. That is, BOUNDS, DIMENSION, and RANK. If these are described as separate attributes, the rule against double- declaration of an attribute appears ineffective, e.g. for INTEGER,RANK(3) :: x,y DIMENSION x(*) ! ??? COMMON /cb/ y(100) ! ???!!! This would be fixable by having BOUNDS and RANK specify the DIMENSION attribute. TECHNICAL COMMENT: All attributes are specifiable both via attr-spec and separate specification statements, and we say that explicitly in the standard. Except that would become untrue for these new ones. We could change that statement, but then it would be inconsistent and inconsistency is often undesirable. Having them all specify the same attribute would reduce the inconsistency. TECHNICAL COMMENT: We should not introduce a new keyword unnecessarily. The syntax within the BOUNDS keyword is orthogonal to the syntax within the DIMENSION keyword; that is, there is no reason not to use the DIMENSION keyword instead of a new one. TECHNICAL COMMENT: It would be highly irregular to have an array syntax specification that can appear only in an attr-spec and not in an array-spec. And indeed, there is no ambiguity between the proposed syntax within BOUNDS and the syntax in an array-spec. Thus we could kill four birds with one stone by adding that syntax to array-spec instead of adding a new keyword. TECHNICAL COMMENT: The things declared with BOUNDS are not any kind of array, though they are clearly intended to be explicit-shape and assumed-shape arrays. The very definition of explicit-shape rules out the possibility of them being explicit-shape; there is no such problem with the definition of assumed-shape, but by omission they are not assumed-shape nor do they have the semantics of assumed-shape. Doing this within the confines of a BOUNDS clause would require a large number of wording changes. Incorporating them into DIMENSION would still require a lot of wording changes, but not as many. Abandoned for now. This paper was processed again later. 20-158r3. The "this is what it should look like" includes several edits that do not appear in the "edits". These comments are from the edits not the "what it should look like". DIFFERENT: [190:24] Joined the run-on sentence with semicolon instead of comma-"and". DIFFERENT: [190:26 p3] you forgot to delete ", POINTER". EXTRA: You forgot to delete "If the construct entity has the POINTER attribute..." Done. 20-153r1. Done. 20-133r3. Done. 20-156r1. Done. 20-163. Done. 20-148r2. DIFFERENT: [56:35+] "If data-ref" -> "If the data-ref". "have" -> "have a", "parameters" -> "parameter". COMMENT: "shall have no assumed or deferred type parameter" might be even better. DIFFERENT: [56:38] Instead, insert "with a data-ref that is not unlimited polymorphic". (Still ugly, but I object to starting the sentence with a condition on an unestablished syntax term. Perhaps this could be wordsmithed some alternative way at a later date?) DIFFERENT: [56:39] "If data-ref" -> "If a data-ref". (Grammar) DIFFERENT: (Such that the resulting paragraph reads:) Did not delete the last sentence of the paragraph, but I did append the sentence. COMMENT: Even though duplicative, I think it might be better to have separate paragraphs instead of this messy one, viz: "TYPEOF ( data-ref ) specifies the same type and type parameters as the declared type and type parameters of data-ref, except that a type parameter is deferred if it is deferred in data-ref. An entity declared with TYPEOF is not polymorphic even if data-ref is polymorphic. CLASSOF (data-ref), with a data-ref that is not unlimited polymorphic, specifies the same type and type parameters as the declared type and type parameters of data-ref, except that a type parameter is deferred if it is deferred in data-ref. CLASSOF ( data-ref ), with a data-ref that is CLASS (*), is equivalent to a CLASS (*) specifier. An entity declared with CLASSOF is polymorphic even if data-ref is not." NOTE: This is a suggestion for next time, I did not do this at this time. Done. 20-160r3. DIFFERENT [190:31-32 p3] Did not delete the comma (the edit said to, but the "reads" said not!). Used the correct verb form "begins" (subject is "execution", which is singular; yes, it sounds a bit clumsy, but there we are). 20-131. Edit was at [121:11-12] in 20-007. Added requested remark in the intro. Done. 20-144r2. [Introduction Data usage and computation] COMMENT: Vector subscripts already specify a sequence of subscripts. The second sentence is misleading to the point of uselessness. DIFFERENT: Changed to "Arrays can be used to specify multiple subscripts and multiple subscript triplets (ref)." It's not great, but at least it gives a hint. [128:6-7 9.4.2 Structure components] DIFFERENT: Declined to delete the indefinite article (grammar). Retained "shall equal the rank" instead of changing to "shall be equal to the rank". COMMENT: "shall equal the" occurs four times, "shall be equal to the" occurs seven times, one should probably be changed to the other. [128:18-19 Structure components p2] DIFFERENT: Declined to change the form of the sentence, just replacing the last part "is the number of..." DIFFERENT: "the size of one" -> "the sizes of one" COMMENT: This still reads very awkwardly. Maybe we should define "The rank of a multiple section subscript is the size of one of its arrays." then we could say "and the ranks of each multiple section subscript" ??? Anyway, it would be good to give this some more wordsmithing to make it a bit less awkward/ugly. [130:23+ 9.5.3.1 Syntax in 9.5.3 Array Elements and Sections R919+] COMMENT: The subclause title specified in the edit is completely wrong: Someone missing a copy-paste key? DIFFERENT: Inserted C926a here where it belongs, and reworded correctly. [130:24+ 9.5.3.1 Syntax in 9.5.3 Array Elements and Sections R920] COMMENT: When editing a BNF term, PLEASe specify the name of the BNF term and not just the rule number. Rule numbers are automatic so do not appear in the LaTeX source (unlike the names). [130:25+ 9.5.3.1 Syntax in 9.5.3 Array Elements and Sections R920] COMMENT: A "multiple-section-subscript" is not a multiple section-subscript as it does not specify multiple section-subscripts, but a multiple subscript-triplet, as it specifies multiple subscript triplets. So I changed the BNF term to "multiple-subscript-triplet". [131:2+ 9.5.3.1 Syntax in 9.5.3 Array Elements and Sections R921+] DIFFERENT: Used a different name. TECHNICAL CHANGE: Made the second optional. (Evidence elsewhere in the paper suggests that that was the intention.) [131:4+ 9.5.3.1 Syntax in 9.5.3 Array Elements and Sections] DIFFERENT: Inserted these immediately after their syntax rules. Reworded correctly. COMMENT: Relying on conformability to prevent rank>1 is a bit subtle. UNRELATED COMMENT: C928 (which is C929 in 21-007) could be shortened to "C927 A vector-subscript shall have rank one." as "int-expr" is already constrained to be type integer, and only arrays can have rank one, and the BNF ref is totally pointless. [131:7+ 9.5.3.1 Syntax in 9.5.3 Array Elements and Sections] DIFFERENT: Reworded to apply only to assumed-size arrays. [131:11- 9.5.3.2 Array element order-] DIFFERENT: "section boundaries or strides" -> "triplets". Inserted necessary comma after the relative clause! DIFFERENT POSITION: I think this should be at the end of the section specifying the semantics. Call me old-fashioned if you will, but semantics first then examples is what I expect. [131:11- 9.5.3.2 Array element order-] DIFFERENT: "one-dimensional" -> "rank-one". twice (We only use "one-dimensional" in comments, and only twice, in normative text we use "rank-one" 34 times.) " size of an that is an array" ->"size of one of its array s". COMMENT: 9.5.3.3.2 Subscript triplet, p1, "An omitted first subscript in a subscript triplet" probably should be "...", but it doesn't really matter (because the omitted exprs in a multiple-subscript-triplet don't result in omitted subscripts in the triplet). Done. N2179-1 (which, with changes, became draft Corrigendum 1). NOTE: (a) refs in the comments are to 18-007r1 not 20-007. (b) some of these changes were in my comments on the Corrigendum, so included in the actual Corrigendum. COMMENT: - "internal subprogram" is inconsistently indexed (it is a defined term) in c01 itself. - Should the definition of the defined term "internal subprogram" reference R502 internal-subprogram? DIFFERENT [101:13-14] Instead, before "a dummy data object" insert "an associate name or". (there is no need to spell out here how an associate name can get to be assumed rank, and it is described just a few lines earlier anyway!) EXTRA for [167:8] Changed "pointer object is not elemental" to "pointer object cannot be elemental", as this seems more accurate. EXTRA for [175:21] Append ref after "pointer association context" (there's no ref after the immediately preceding "variable definition context", because there is one after the previous vdc in the same sentence). EXTRA: Do the same edit to the constraints that this text duplicates, i.e. Append to the sentence "or pointer association context (ref)", in [174:16] 11.1.3.1 Purpose and form of the ASSOCIATE construct, C1101. [194:1] 11.1.11.1 Purpose and form of the SELECT TYPE construct, C1158. COMMENT: Why is there no such constraint for associations in CHANGE TERM and SELECT RANK? It would be more consistent to have such constraints. And if we had such constraints, we could change the "shall not" in the duplicative normative text to "can not" (or even delete the duplicative normative text altogether). Here are the constraints I am suggesting (I did not do these): [177:24+] 11.1.5.1 Purpose and form of the CHANGE TEAM construct, after C1116, new constraint "C1116a If the \si{selector} in a \si{coarray-association} is not permitted to appear in a variable definition context (ref), the \sinr{coarray-name} in its \si{codimension-decl}, or a subobject thereof, shall not appear in a variable definition context or a pointer association context (ref)." [191:12+] 11.1.10.1 Purpose and form of the SELECT RANK construct, after C1150, new constraint "C1150a If the \si{selector} in a \si{select-rank-stmt} has the \attr{INTENT (IN)}, the \sinr{associate-name} or a subobject thereof shall not appear in a variable definition context (ref) or a pointer definition context(ref)." COMMENT [204:35] actually the term to be indexed is "sibling teams". [380:12-13] Ditto. [401:24-45] (sic) Ditto. [421:9] Ditto. COMMENT TO EDITOR: All the "image 1" appearances in the std really should be "image one". (I should have done this in 21-007 already, but I forgot.) DIFFERENT [340:34-35] Comma needed after "nonnegative" otherwise we have "A and B and C", and we want C to apply to B and not to A!!! WRONG REF [401:24-45] should be [401:24-25] (obviously). EXTRA EDIT [408:36,39] to [409:3] for IDENTITY, insert "declared" before "type and type parameters". EXTRA NEEDED: [528:22+] adds another feature that was *not* subsequently added to the Introduction by TC, therefore [528:23] same subclause p2, "two" -> "three". Done. NOT A PAPER. Fix example in C.4.1 which did not compile. Done. NOT A PAPER. Hyperlink IEEE_SUPPORT_STANDARD ref in 17.9p7. Done. RANDOM COMMENT (no change made to 21-007): Consider: C15101 If a procedure that is not an intrinsic procedure, a module procedure of an intrinsic module, or a statement function is used in a context that requires it to be simple, then its interface shall be explicit in the scope of that use. The interface shall specify that the procedure is simple. This is bad wording because the interface of an intrinsic procedure or module procedure is always explicit, so does not need to be excluded. In fact, this may permit a NON_SIMPLE procedure to be invoked from a SIMPLE procedure, if the NON_SIMPLE procedure is intrinsic or from an intrinsic module. That would seem to be a very bad thing. Fix: delete "an intrinsic procedure, a module procedure of an intrinsic module, or" 20-135r1 second attempt. Here are the significant changes that I believe are needed to make this work properly. TECHNICAL CHANGE: The syntax previously inside BOUNDS is instead added to array-spec, thus - permitting its use inside a normal array-spec after a variable or component name, - avoiding the unnecessary introduction of a new keyword, - avoiding introducing something that cannot be specified in a separate statement, - avoiding attribute confusion (it's all the DIMENSION attribute). EDITORIAL CHANGE: Describe RANK(...) as a RANK clause, not a RANK attribute, and say that it specifies the DIMENSION attribute. COMMENT: Integrated the rank-independent syntax directly into the relevant subclauses of DIMENSION, adding constraints and semantics that were missing from the paper. Quite a lot of additional text and explanation has been added (but I cannot claim that I caught everything). COMMENT: The proposed examples were mostly added to the main set of DIMENSION examples, with uninteresting ones omitted and extra ones added. EXTRA: Fixed definition of deferred-shape array to permit the RANK clause. Fixed explicit-shape array defn to permit rank-independent syntax. Admit that the DIMENSION attribute can specify that things are scalar. While integrating into explicit-shape arrays, shuffle the paragraphs into an order that makes more sense: rank, specification of the bounds (two paragraph, one for each syntax), semantics of the bounds, and finally automatic array effects. Similarly, swapped paragraphs 3 and 4 of assumed-shape (so it is rank, specs, semantics). TECHNICAL CHANGE: Added constraint that the value in RANK(n) must be less than or equal to the max rank supported by the processor. That's to avoid arguments over whether "REAL,RANK(99999) :: X(3)" is valid - IMO it should not be valid, and the constraint makes it clear. TECHNICAL COMMENT: I really do not like ambiguous syntax, or unambiguous syntax with ambiguous semantics. The RANK clause can be used to declare both deferred-shape or assumed-shape arrays, depending on whether an entity is a dummy argument. This has several problems: 1) it is semantically ambiguous, as I noted already, 2) the name RANK gives no real clue as to its purpose, 3) for assumed-shape it can only declare arrays with lower bounds equal to one, entirely redundant with DIMENSION( [ (1,i=1,n) ] ) Thus: I would prefer this clause to be limited to deferred-shape arrays. I would also prefer it to be called DEFERRED_SHAPE(n); yes, when n==0 it's not an array so not really deferred-shape, but I see that as a far lesser glitch than the current vagueness. COMMENT: We now have four ways to declare an entity to be scalar: 1) just don't give it the DIMENSION attribute anywhere; 2) RANK(0) ! Dummy or Allocatable or Pointer 3) DIMENSION([Integer::]) ! Anything 4) DIMENSION([Integer::]:) ! Dummy Apart from removing the "Dummy or" possibility from case (2) - see my previous comment - I don't have any concrete suggestions for tidying this up. Untidiness is not such a big problem anyway - better to be a bit untidy than to leave out needed functionality. But if someone has a bright idea... Done. NO PAPER. Hyperlinked IEEE_SUPPORT_STANDARD on the first page of clause 17. Done.