J3/01-101 Date: 21 Dec 2000 To: J3 From: Richard Maine Subject: Edits incorporated in 01-007 This paper describes the changes in J3/01-007 relative to the previous f2k draft, J3/00-007R3. All page/line references are to J3/00-007R3 unless otherwise noted. Ths change bars in 01-007 are relative to 00-007R2. (Sorry; they should be relative to 00-007r3, but I apparently forgot to clear them before starting the new edits.) This includes edits from papers (all 00-) 302, 303, 311r2, 312r2, 313r3, 314r2, 318r1, 320r2, 323r3, 326, 327r1, 331r1, 332, 333, 334, 335, 336, 338r2, 339r2, 340r1, 341r1, 342r1, 343, 344, 345, 346r1, 347r1, 351, 352, 353, 354r1, 355 misc edits not in papers [370:14] "function" -> "subroutine". paper 00-302, with the following changes I still think the second edit reads pretty badly, but that's what we passed, so that's how I entered it. In the note, I changed "prevents attempting to create" to "avoids the creation of". This doesn't prevent you from attempting anything - it just says your attempt won't succeed. I still think it unhelpful to talk about activation records without even a vague definition of the term, but that comment elicited no support on the floor, so I've entered it as passed. paper 00-303, with the following changes Also deleted "the" from [72:1]. paper 00-311r2, with the following changes Kept only one of the "the"s in "the the" (twice). Deleted "is selected" on [350:43]. Paper 311r1 had a replacement of this with a new sentence. I requested this edit be deleted for the r2, but my request was sloppy and was only intended to avoid the addition of the new sentence. The "is selected" still needs to go. paper 00-312r2, with the following changes Also changed "Objects"->"Entities" in the title for 4.5.12 so that the title agrees with the content. Added a comma before the insertion at [121:37]. paper 00-313r3, with the following changes [280:22] Fixed so edit didn't leave an incomplete sentence. [287:44], [312:39] Didn't do this one (for ISHFT). In this case "logical shift" is the correct, widely used, technical term and distinguishes this from an arithmetic shift. I disagree that there is any danger here of confusion with logical variables - anyway not enough to take out the accepted technical term for this. (What would a logical variable shift be?) I can see confusions in things like "logical or" and the others, but not here. There is much more danger here in not using the standard term for this operation. If people insist, of course, I'll do the change, but I think this one a bad idea on closer inspection. paper 00-314r2 as is paper 00-318r1 as is paper 00-320r2, with the following changes [41:33+] Since this added the same 2 xrefs as the constraint 2 below, deleted them from that constraint. Xrefs are pretty inconsistent throughout the document. Some places too sparse. But other places too redundant. We don't really need multiple xrefs of the same things in close sucession; it's just distracting. Added a missing comma after one of the dtv-type-specs. Two typos later pointed out by Van in the edit at 350:35-43. Deleted the "if" in the 4th item and changed the last comma in the 5th to a period. paper 00-323r3, with the following changes I'm still puzzled about why a single paper uses two different ways of talking about the same thing ("initial mode" vs "initial value of a mode"), but at least this is better than three. I've spent enough time on that aspect of this paper; entered as is in the paper. [172:25+] Combined this with (11) instead of adding a new item. [173:18+] "unit" -> "connection" and "on that unit" -> "for that connection". The modes are associated with the connection - not the unit. The paper even says so repeatedly in later edits where it talks about the modes for connections. C.6.5 talks about some of these things as connection properties, etc. Hmm. I see that some of the existing text is inconsistent about that. Oh well. Omitted comma. [177:22-28] "sets" -> "specifies". The specifier doesn't set anything; it just specifies it. See similar wording in other subsections here. Similar changes in [177:32] and [178:17+]. [178:17+] Put PROCESSOR_DEFINED last instead or first in the list. Likewise put S last instead of first (so that it still corresponds). Same 2 changes in 9.5.1.14. And also list S last in 10.7.4 for consistency (it is already described last, although listed first). Likewise in R1015. [178:17+] For now, "file connected" -> "file being connected" so that at least it is like other sections here. Probably want to come back later and fix all these...they should say things like "for a connection...". Its for the connection, not the file and not the unit. [180:30+] "An" -> "A" [181:13] Added a comma. [184:16+] I don't really see anything wrong with "It specifies" (the antecedant of "It" being ). But that's not the phrasing used in any of the other specifiers here. Since the title of the paper says "regularize", I'd think it best to make a point of using the same phrasing for the same thing unless there was an actual reason for a difference. Looks like this wording was almost copied from that for decimal= or round= (which seems fine), but with minor random wording changes added, which doesn't seem so fine. If the revised words are deemed better, then they ought to be used in the existing sections also. The revised words mostly just look trivially diferent, neither better nor worse. I regularized the words by using the same ones as for decimal= and round=. Thus "It specifies" -> "The xxx= specifier specifies", "the initial value of the xxx mode" -> "the initial xxx mode", reversed order of internal/preconnected phrases (the articles avoid misparsing). (4 times). In the other direction, the new wording about most recently is definitely better, so I copied it to the decimal= and round= sections; I've no idea why the paper didn't. Also made the bit about most recent open refer to connection instead of the file in all 6 places. We sometimes use file, sometimes unit, and sometimes connection. In the name of regularization, I tried to consistently use connection, though I didn't go through the whole section to find all occurances. I deleted the xref after "opened with no xxx specifier" in all 6 sections. In every case, it is at least the 2nd occurance of the same section xref from the same paragraph; in some cases it is the third. That doesn't seem helpful. Delete "one of" from SIGN=. I dunno why it was the only one of the 6 to use those words in that context. "input" -> "output" for sign= mode. (Was right one place; wrong another). The 4th sentence in 9.5.1.14 was an almost verbatim repeat of the 2nd with an inconsequential diference. I assumed this must have been a mistake. I put the sentence in only once. Since the bit about correspondence to SP, SS, and S edit descriptors is explicitly expressed in terms of order (with "respectively"), I moved that sentence up so that the "respectively" is nearer to the list it refers to rather than being separated by an unrelated discussion of how the initial mode is determined. [203:10-12] Left original "input/output" rather than making an incompatable change to "input". There is no relationship between the allowability of a BLANK= inquiry and the ACTION= specifier of OPEN, which is the closest thing we have to a concept of a connection restricted to input. Also reworded to refer to the connection instead of a file. Similar changes for delim, pad, sign. Similarly changed the file bit to refer to the connection for round and decimal. Deleted "one of" from the inquire SIGN= also. There was a strange consistency about the inconsistency here, both SIGN= being inconsistent in the same way, but I'm not sure where it arose from. If there weren't so many other inconsistencies around, I might suspect I was missing something subtle. Later...say, I see round= previously did this also. Made it consistent as well. [230:40-44] Added a comma. 10.7.6 on BN and BZ says the same thing redundantly several times. It says that BN and BZ affect the blank interpretation mode; then it says how blanks are handled with blank interpretation modes of null and zero; then it says how blanks are handled with bn and bz; then it says how BN and BZ affect the blank interpretation mode. I left it as is, being a bit tired by now. paper 00-326 as is paper 00-327r1, with the following changes Only capitalized the first word of 14.6.5 heading. Used numbered list instead of bulleted one (just because that's what we almost always do and what there was already a Frame template for in this chapter). Minor rewording of the array part of the first bullet item. Mostly to use "become" instead of "has" to indicate a change of state. Also minor reordering of the phrases in the process. "if an array" -> "if it is an array" "if defined" -> "if it is defined" (twice) "become that" -> "become the same as those" (twice). For number agreement and because we use "the same as" for the other cases, so we should also here (and it seems better anyway). Reworded last clause of 2nd bullet because the antecedant of "its" was confusing. So just spelled it out instead of using "its". paper 00-331r1 as is paper 00-332 as is paper 00-333, with the following changes "The" -> "A" in the edit at [39"42+] paper 00-334 as is paper 00-335 as is paper 00-336, with the following changes Same change on 395:29 and 400:47. paper 00-338r2, with the following changes Add a comma at [353:18] Since linkage association is listed as a form of name association, its new section goes as a subsection of the name association section, and in the order listed. So it becomes 14.6.1.4 at [355:44+] paper 00-339r2, with the following changes Add "; this is" before "because" in the note. (Help parsing). Add "connected for stream access" in the note because the statement might be misconstrued to apply too broadly otherwise. paper 00-340r1, with the following changes the first "or" -> ",". paper 00-341r1 as is paper 00-342r1 as is paper 00-343 as is paper 00-344 as is paper 00-345 as is paper 00-346r1 as is paper 00-347r1, with the following changes Added a comma in the constraint. No "the" before . (3 cases) This one is actually pretty important. We have had substantial confusions in this section before. There are two different things that should *not* be confused. There is "the target", with an article and without italics. That is what the pointer ends up pointing to. And then there is "", in italic and with no article. That is part of the bnf. The two are critically different. For example, may be a pointer, but the target never is. Please do not confuse the two. This is one place where a "the" does matter. There is only the "the" and the italics to distinguish the two cases. Perhaps things would be less confusing if the bnf term used a word other than , but that's the term it currently uses. Since one of the new sentences uses (and means) both "" and "target", it is really important to avoid confusion or the sentence becomes incomprehensible. (You'll have readers asking how the target can be a proper subset of itself). Some of the constraints start with "The " to avoid starting a sentence with bnf, but don't just add the "the" arbitrarily. Likewise no "the" before some cases of "", though there isn't such obvious potential for confusion here. While on the subject I deleted about a bazzillion (I lost count) similar cases of "the" before these 2 bnf terms in the para at [140:36-40]. (Perhaps that's where you copied the style from). [139:17] add "for " after 2 cases of "If an is specified". An upper-bound may be specified for variable (to point to an array slice), but I seriously doubt you intend these conditions to apply to that case - it would break huge amounts of existing code. I came awful close to adding an unresolved issue for the last sentence of the para added at [140:11+]. I even wrote one up, but then deleted it because I guess the sentence might be ok. Still, someone else might want to read it critically to decide whether it isn't too self-referential. I found myself getting pretty confused about precisely what this was saying. It kept sounding like the target was being defined in terms of itself. I finally concluded that perhaps it was ok....but I still find that it reads a bit strangely. paper 00-351, with the following changes Added a comma in the first edit. In the new glossary entry, consistently use "in" instead of "by", just like in several of the other edits. paper 00-352, with the following changes The changes in c13 weren't really quite as "the same" as advertised. I used the correct heading syntax for the cases where there were already other optional arguments. (We put all optional arguments in a single set of square brackets in such cases). Indeed, LEN was in a distinct minority here; it was closer to the exception than the rule. And did not change "Argument" to "Arguments" where it was already that way. (I rather doubt it was intended to end up as "Argumentss"). When we change "Argument" to "Arguments" we also go to a different paragraph style, putting the first argument in a separate para instead of on the same line as the heading. (One could perhaps argue that consistency between the singular and plural forms might have been a good idea...but that's not the way the document currently is). Changed both forms of MAXLOC and MINLOC. I assume that was the intent. That is a technical question rather than an editorial one...even though it's a technical question with what I assume to be an obvious answer. On a matter that is editorial, I omitted 2 blanks in the MAXLOC and MINLOC headers. Stylistically, the blanks belonged there, but I didn't want to try to deal with a header that no longer fit on one line (which it didn't). I replaced only the first sentence (rather than the whole line or para) of most of the "result charactersitics" sections. And changed "It" to "The result" in the second sentences because the referent for "It" was no longer clear. Again, LEN was in a distinct minority here. Hmm. An now that I notice it, LEN was done wrong. The edit omittted the scalar part. For LEN, that is important. I guess I better actually study each one of these cases, as it is obvious that the author did *NOT*. SIZE also edited out the scalar bit; transformationals are different from elementals; the difference can be important. I rewrote the one for SHAPE because the former first sentences mixed some things that are replaced with some that weren't. Not that it was hard to rewrite, but it just makes me disbelieve that anyone other than me actually looked at each of these edits. My acceptance of "do the same thing in a lot of places" kind of edits is conditional on someone else having at least done a token check that "the same thing" is the appropriate edit. When such a token check so obviously has not been done, credibility about such things in the future suffers. Was it possible to read all these "result characteristics" clauses without noticing that they differed - sometimes in substantitative ways? paper 00-353 as is paper 00-354r1 as is paper 00-355, with the following changes I normally avoid beginning sentences with bnf, even adding otherwise superfluous articles if needed. But I see there is plenty of precedent for the exact wording used in the new constraints here, so I'll leave them as is for consistency, rather than "fix up" all the existing cases. Similarly, "in the module" would be better as "of the module" when modifying "public entity", but it's already used incorrectly about as often as it's used correctly (if not more so), including in a bunch of cases right in this area, so I'll enter it as is.