J3/05-169 To: WG5/J3 From: Malcolm Cohen Subject: Editor's report on incorporation of the EM TR Date: 2005/03/15 1. Introduction Two comments on producing edits for ISO/IEC publication: (i) Turning line number references into prose is not terribly helpful. I'd prefer to see more context, and less counting, in these edits. When counting is necessary, counting sentences is easier than lines. (ii) Each edit should indicate which subclause to which it applies. For example, just saying "R1228" is not good enough. 2. Typesetting Problems The edits for table 2.2 were impossible to typeset. For now, I have abbreviated "Statement function statement" to "Statement function stmt." to get enough horizontal space. It is still 1.8points too wide. I recommend that this table be deleted in the next revision. It provides no information above what is provided by the syntax rules. 3. Solved Editorial Problems, Wordsmithing, etc. a) The last instruction for 2.2 was ambiguous: there were two "module"s on that line. I did "In the last sentence of the first paragraph of subclause 2.2 insert ``or submodule'' before ``but''." b) The edit for Note 4.40 is horrible. The module only contains a single type definition. It makes the user think "how can this have submodules" instead of "ah, so that is a type with private components". (The submodule cannot affect the program anyway, as far as I can tell.) I did the easy fix of deleting the MODULE and END MODULE statements, leaving just the type definition, the same as it is in Note 4.41. c) The edits for the second sentence of the second paragraph of 4.5.5.2 made it ungrammatical, due to incorrect positioning of commas. Instead, I did In the second sentence of 4.5.5.2, after "in a module" insert "or submodule," and after "referencing the module" insert "or accessing the submodule". This sentence is still hard to read: see unsolved editorial problem 1. d) The new section 11.2.2 contained the text "... is its parent; its parent is ..." Fixed by changing the text to "... is its parent, and is ..." (This is papering over the cracks though, because the paragraph in question contains an Unresolved Technical Issue, as well as fairly unsatisfying prose.) e) In the new 11.2.2, C1114c was "If an object of a type for which is specified (R444) is declared in the of a submodule and does not have the ALLOCATABLE or POINTER attribute, the object shall have the SAVE attribute." Reworded to make it shorter and to use similar terminology to elsewhere as "An object with default initialization that is declared in the of a submodule shall have the ALLOCATABLE, POINTER, or SAVE attribute." (NB: There was one place in the standard where the clumsy wording was used, and C1114c copied it. That place - C1107 should also be fixed.) f) The insertion defining a module procedure interface body (after constraint C1211) has the phrase "its name has the PUBLIC attribute". This occurs once elsewhere in the standard - normally we say "is public" or "is accessible". Changed to "is public". g) Ugly prose in new constraint "A scoping unit in which a module procedure interface body is declared shall be a module or submodule." Reworded as "A module procedure interface body shall appear only in the scoping unit of a module or submodule." (This is more like existing text.) h) The keyword listing for R1228 was in reverse alphabetic order. Cute, but hardly useful. Since I was editing the list, I fixed the ordering. i) Changed a postfix condition "and is accessible by host association from that ancestor" to a prefix condition "accessible" twice (C1242b, C1251a). j) First sentence in note 12.40 and a half said: "A separate module procedure can be accessed by use association if and only if its interface body is declared in the specification part of a module and its name has the PUBLIC attribute." simplified this to "A separate module procedure is only accessible by use association if its interface body is declared in the specification part of a module and is public." I'm not sure that we need this note at all (the point is not all *that* subtle), but we certainly don't need it to point out that if a particular something is PUBLIC then it is accessible! k) "If a is specified in the , it shall be identical to the specified in the ." Should be "If a appears in the , it shall be identical to the one in the ." The existing text in the standard has some problems, not least of which is the inconsistency between end-program, end-blockdata, end-module, end-function and end-subroutine, but that will have to wait. l) C1114e had the wrong back-reference (it should have been R1115a). m) Edit says "In the list in subclause 16.0". There are two lists; a bullet list and a numbered list. This edit refers to the numbered one. Then, it says to put the new insert after item (1). This is out of place; the other items are in order of appearance in the standard. I put it after item (4) which is where it belongs by that rule. n) Second edit for 16.1; "A submodule identifier of a submodule" should be "The submodule identifier ..." (c.f. the previous sentence; a submodule has one definitive identifier, thus it is *the* identifier). o) The edit for the "fifth line of the first paragraph of subclause 16.4.1.3," says to insert something after "abstract interfaces". This phrase does not appear there. I made the edit to the last sentence of this paragraph, which does contain that phrase - on the 6th line. p) The inserted text for 16.4.2.1.3 ends with a full stop but a comma is required. q) Glossary definition of "correspond". The verb is being used within the normal English usage. Furthermore, we use correspond with that usage *EVERYWHERE* throughout the standard with arguments, components, etc. FurtherFurthermoreMore, this is not a definition of the word but a mere restatement of the conditions for this particular correspondance to happen. As putting the conditions for just this one in would be seriously misleading, this edit was therefore omitted. r) Other glossary definitions are all bad. They variously grab the root name of other technical terms already in use (as if they had come first), the wording is faulty (e.g. using the multiple-choice wording "Of a ..." when only one choice is being presented), giving "explanations" that are just regurgitations of constraints and syntax, and generally being unhelpful. For now, I've omitted all of them except for: (a) "module procedure interface"; this glossary entry raised a technical issue which affects clause 12, so I'm letting it stand just for that. I did change the text to omit the syntax junk and just have the explanation (it was the explanation that was at odds with the normative text in C12). (b) "submodule". This entry really should be here. The text was wrong though, so I reworded it. It might still be wrong! s) The insert for C.8.3.9 had the syntax term . There is no such animal. Fixed to . t) The paragraph defining a module procedure interface had poor style ("includes MODULE" forsooth). Rewrote the first sentence as "A <> is an interface body whose initial statement contains the keyword MODULE." u) Subclause 12.5.2.4 also suffered from "includes MODULE". Simplied "in which the of the initial includes MODULE" to "whose initial statement contains the keyword MODULE" twice. v) C1242a (C1245): the second half of this constraint duplicates C1211a. Deleted C1211a. w) Added a reference to (12.5.2.4) at the end of the insertion into 16.3. 4. Unsolved Editorial Problems These will probably be solved by editorial fiat before the first "real" draft WD. They are here usually because the solution is less obvious, more widespread than affecting just the EM TR bits of the standard, or don't really need fixing immediately. The editor will probably fix less obvious ones as soon as he has decided what to do, and the other ones as soon as time permits. 1. We should use the same language for accessing/referencing both a module and a submodule, so that we do not have this ugly "Xing the module or Ying the submodule. Note that the existing standard uses at least 3 different forms of Xing a module already. 2. The paragraph defining a module procedure interface has ugly typography. Can it be improved? 3. Subclause 12.5.2.4 is very duplicative of text elsewhere e.g. in 11.2.2. This should be simplified. 4. In the new 12.5.2.4, "A module procedure interface block and a separate procedure <> if A, and B or C and D." Yes, I can work it out. No, it's not fun. It should be simpler. 5. There is no number 5. 6. "A module procedure interface block and a separate procedure <> if A, and B or C and D." This is very hard to parse. There must be a simpler wording, even if that would require breaking it into two sentences. 7. 12.5.2.4 first sentence says "A <> is a module procedure defined by a ..." This is unfortunate terminology to say the least. It is not a module subprogram (there is no such thing). It muddies the waters to call this particular one a "" and not the other two. 8. A "<>" should probably *define* the module procedure interface, not simply declare it. 9. The proposed glossary definitions do not seem particularly helpful. In many cases they should simply be deleted, as the terms are always being used already within their special context and not on their own. i.e. They deserve index entries not glossary entries. I think that applies particularly to "ancestor", "child" and "descendant". Note that the i/o version of "child" is not present here, so this one is arguably technically deficient as well. 10. The "parent" of a submodule would appear to be simply the "host" of the submodule. If it's not, host association does not work. If it is, we should delete the term "parent" (of a submodule) and use "host" instead. 11. The definition inserted in the fourth line of 2.2 is inconsistent "A submodule is an extension of a module" but then goes on to talk about the module "or another submodule". 5. Solved Technical Problems 1. Missing edit for Note 12.3, which said "An interface body cannot be used to describe ... a module procedure". Fixed by adding "that is not a separate module procedure". Ugh. 2. The second sentence of Note 12.40 and a half said: "A separate module procedure that is not accessible by use association might still be accessible by way of a procedure pointer, a dummy procedure, a type-bound procedure, a binding label, or means other than Fortran." This appears to be an attempt to make a comprehensive list. Unfortunately, it is incomplete: the obvious omissions are (i) via a generic identifier (ii) via host association The whole thing boils down to "if you don't have direct access to the name of a procedure you might still be able to invoke it by some other means". We don't need to point this out, and we don't need more hostages to fortune embedded in notes in the standard. Fixed by deletion. 3. 11.2.1 does not provide access to separate module procedures, because they are not module entities (if they were to be considered such, lots of our other inserted text would be broken). And it does not provide access to module procedure interfaces because they don't appear in the list of things exported. Fixed by adding ", module procedure interfaces" to the list in the second paragraph of 11.2.1. 4. "The <> consists of the ancestor module name together with the submodule name." I don't recognise the "together with" operator: one might guess that it means concatenation, a set, or an ordered pair. Assuming the intention is the latter, I changed it to "The <> is the ordered pair whose first element is the ancestor module name and whose second element is the submodule name." 6. Unresolved Technical Issues Here they come again. I bet you all wish you'd seen the last of them. (5000) The phrase "its descendant submodules" looks redundant but is incorrect. The term is never defined, and "its submodules" is defined to mean only the immediate submodules. Since adding a qualifier cannot extend a class, that's all it means. This occurs in c04 and c05, and elsewhere. (5001) No definition of what "accessing [a] submodule" entails. I don't think this means host association, because even if no entity is accessible via host association (perhaps because an intermediate submodule has hidden it) one still wants a procedure executing in one of its submodules to be considered to be "accessing" the submodule. Or does one? COMMENT: The whole dichotomy between "referencing a module or accessing a submodule" serves only to obfuscate the TR and uglify the text, since "accessing" a submodule is not any better defined than "referencing" a submodule. (5002) "the interface may be used to specify an explicit specific interface but the procedure shall not be used in any way" Actually, this does not makes sense. If this thing isn't a procedure we cannot ever invoke it (the USEr of a module does not have access to the submodule or the procedure therein - it only has access to the interface). And if it is a procedure, using it to specify an explicit specific interface is using it in *some* way. So feeping creaturism has struck again - cute to have this pseudo-library stuff, but now we don't know what is what. (5003) The "module procedure interface" glossary entry is incorrect. A Module Procedure Interface Block declares a Module Procedure Interface, but not a Separate Module Procedure's Interface unless the Separate Module Procedure is defined by an Separate Module Subprogram (sic). This raises the question of whether the whole definition/declaration stuff in C12 is consistent and correct. It looks like it is probably inconsistent, since one cannot know when translating the module whether the MPIB should be treated as declaring the SMP's interface or not. When C12 has been fixed, the glossary entry can be reconsidered -- and deleted if it is not useful. (5004) The "parent" of a submodule is not its "host". Without this, host association does not work properly (the words are broken). Rather than fix references to the "host" to be "host (or parent of a submodule)" we should fix the definition of "host". Note that references to the "host", "host scope", or "host scoping unit" ("host scope" is I think a mistake, but anyway...) appear in clauses 2, 4, 5, 12, and 16. 7. Other outstanding issues - There is now a constraint "If the USE statement apppears within a submodule, shall not be the name of the ancestor module of that submodule (11.2.2)." Two issues: (a) This should be simplified to something like "Within a submodule, a USE statement shall not reference the ancestor module." (b) It is inconsistent that this is a constraint and yet the requirement for a module not to reference itself is not. ===END===