ISO/IEC JTC1/SC22/WG5 N1544 Typos and editorial trivia in 03-007 Richard Maine This is a revision of N1527. It adds more material and was reorganized. This paper has edits to correct some typos and editorial trivia in 03-007. All page and line references are to 03-007. I. Typos and errors Thanks to Aleksander Donev, Dick Hendrickson, Bill Long, Van Snyder, Craig Dedo, and James Giles for pointing out most of these; for the most part all I did was collect them. [44:19] "accessibile" -> "accessible" [44:23] "USE" -> "use" [47:Note 4.24 2nd line] "to to" -> "to" [47:16] "sitype-param-decl" -> "" [55:10] "" -> "" [59:Note 4.51] Reformat the example as TYPE, ABSTRACT :: FILE_HANDLE CONTAINS PROCEDURE(OPEN_FILE), DEFERRED, PASS(HANDLE) :: OPEN ... END TYPE [62:15] !derived-type-spec? -> [69:23] "4.5.3" -> "4.5.6" {I thought some other paper was going to fix this, but I don't see it anywhere.} [74:24] "declaration-type-spec" -> "" [164:23] "paraqmeter" -> "parameter" [164:16,17,21] Use "\si{type-spec}" instead of "\sinr{type-spec}" in the LaTeX source, which won't cause any obvious difference here, but will eliminate the duplicate entry for in the index. [268:Note 12.15] "C_LOC" -> "C_FUNLOC" (twice) [299:29] "allocatiom" -> "allocation" [308:8] "=\pi" -> "-\pi" (where \pi means the math symbol). [327:3,10] "and" -> "an" (twice) [335:26] "upside-down !" -> "<" [337:1] "<" -> "<=" (like in MAXLOC) {That's a less-than-or-equals sign, \leq in LaTeX-speak}. [340:Note 13.15 2nd line] "transfering" -> "transferring" [357:8] Delete 1 of the 2 minus signs. [357:8] "86339" -> "1573039" [418:6] Delete spurious blank after "unit". [434:37] Alphabetize "parent type" correctly; move to (435:2+] [444:37] "Data extension" -> "Type extension" {The term "data extension" is used nowhere else} [445:36] Indent this line like the REAL declarations earlier. [446:7] Delete "! Not shown here" {Lines 12-16 do appear to show it. If the "here" is supposed to exclude those lines, that is unobvious and misleading.} [449:12] The wrong style of dash was typeset, but instead of just changing the dash, a better edit is "-so" -> ";". II. Editorial suggestions A. Nondelimited/undelimited Section 10 has 3 cases of "nondelimited" and 1 of "undelimited". I agree with Dick that "undelimited" sounds better, so I propose changing "[a] nondelimited" to "[an] undelimited" at [240:21], [241:6], [243:3], and [248:4]. Alternatively, we could change "undelimited" to "nondelimited" at [246:Note 10.35 3rd line]. Don't do both edits. (If this paper passes without directions to the contrary, do the 4 changes instead of the alternative one.) B. Since The word "since" is best reserved for contexts where it refers to time. Some of the uses in the draft are appropriate, but others are not. In some cases, it is potentially confusing because time is involved in the sentence, but that isn't what the "since" is referring to. "since" -> "because" (retaining capitalization) at [8:34], [12:Note 2.2], [45:Note 4.21 line 6] [49:Note 4.27], [277:Note 12.31], [347:21], [368:20], [414:Note 16.10 line 19], [440:38], [465:25] "since" -> "in that" at [441:7] (Both "since" and "because" seem wrong here). C. Redundancy in constraint wording. Several of the constraints have redundancies like "(R612) In a ...", where R612 is the definition of . The R612 part *MEANS* "In a ", so this is completely redundant. We don't consistently have this redundancy. Nor do I think these are special cases that merit the redundancy for emphasis. I think these are just holdovers from when the (R612) syntax was added; that addition was done en mass, without any wording changes. The following may not be all the cases, but since we are already inconsistent, so I don't consider the likelihood that this misses some to be a reason not to do it (though if more are noticed, fixing them would also be ok). Delete "In a ," and capitalize the next word at [105:3] (C609), [105:4] (C610), and [105:13] (C614). Delete "In a ," and capitalize the next word at [105:24] (C615), Delete "In an ," and capitalize the next word at [107:11] (C617). Delete "In an ," and capitalize the next word at [107:14] (C618). The following cases have slightly different form and thus need a slight additional wording change. [105:9] (C613) "In a containing" -> "If there is" [107:17] (C619) "In an with" -> "If there is" D. Misleading bnf term N1524 points out that the bnf term causes confusion because we use the Engish word "binding" to mean something different. For example, the use of "binding" at [56:10] does not mean the bnf defined 3 lines earlier, but instead means a , , or , as defined in R444. Although those three things are kinds of bindings, they are not kinds of ; instead a is a syntactic part of a . This is horribly confused. I originally suggested using a different bnf term (possibly would do), but on further study, we don't appear to need a bnf term for this at all. I speculate that the existing bnf term might be a remnant of some earlier syntax. In any case, it trivially factors out of the current syntax without loosing anything except the confusion. [56:7] (R448) Delete the bnf definition of . [55:8,9,10,11(twice)] Change all other occurances of to . (Yes, I verified with grep that these 5 are the only occurances). [56:8-9] Move C462 to [55:10+], renumbering the constraints and changing its (R448) reference to (R445). III. More significant error This possibly should be in a separate paper, as it goes beyond the typographical or editorial level, but I hated to write yet another separate paper. Although this has technical content in changing what is legal, this *HAS* to have been an unintentional oversight...doesn't it? Did we really want to disallow interoperable derived types in COMMON? Even in COMMON with the BIND(C) attribute? I'm assuming that someone just thought that BIND(C) was a specific form of sequence type. (Although I think that would be a fine way to define them, we didn't do so); or perhaps this was overlooked completely. As is, when combined with C561, this disallows all derived types in BIND(C) COMMON blocks. I understand why C597 disallows variables with the BIND attribute, but variables of BIND(C) types, as disallowed by C598 are a different matter. [98:20] "with" -> "or a type with the BIND atribute and it shall have" I'm also not sure whether the similar prohibition against equivalence of BND(C) types is intentional, but that seems less glaringly wrong to me, so I left it alone.