!standard 1.1.3(1/2) 12-03-09 AI05-0293-1/02 !class presentation 12-02-15 !status ARG Approved 10-0-0 12-02-24 !status work item 12-02-15 !status received 11-11-29 !priority Low !difficulty Easy !subject Remove unnecessary hyphens !summary Remove unnecessary hyphens from words prefixed with "non-". !question The standard is inconsistent in the spelling of words that start with the prefix "non". For instance, most text uses "nonlimited", but there is some that uses "non-limited". Similarly, text uses "nonabstract" and "non-abstract" in equal amounts. Differences like this make is harder to search the Standard (as both forms need to be searched). !wording "non-" should be changed to "non" in almost all occurrences in the Ada standard. Exceptions: "non-" prefixing something that already has a dash: non-discriminant-dependent non-library-level non-language-defined non-per-object-expression non-unchecked-union non-subpool-supporting non-Latin-1 "Made up words": non-PI non-Ada non-access non-aliased non-array non-English non-ISO non-held non-protected non-record non-stub non-syntax non-void Oddities: non-others [where "others" is a reserved word.] non-preemptive [this one appears in a clause title.] non-prefixed view [the term is "prefixed view", and this is not one of those; it's not "nonprefixed" (which would mean "not prefixed").] non-spacing [this is a term from 10646, we better not change its spelling.] Note: We are changing these spellings under the assumption that these are typographical errors, and thus are *not* marking these as changes anywhere in the Ada Standard. Specifically, paragraphs where hyphens were removed will not be labeled with "/3". There is an unofficial list of places where these words occur in the first message in the !appendix. We did not check the accuracy of this list. !discussion !ACATS Test No tests needed. !ASIS No change needed. !appendix From: Randy Brukardt Sent: Tuesday, November 29, 2011 12:57 PM Christoph Grein (channeling Gary) sent the following lengthy list of terms that are inconsistently used in the Standard. My initial reaction is to change those that are different only in AARM notes (as that is relatively easy and doesn't require detailed tracking of the changes). But changing normative wording requires a lot more work and deciding which form is better -- two things I'd rather avoid. So I'm not planning to make any changes there. If you disagree on any term in this list, please tell me and explain what you think we should do in detail. Randy Brukardt, ARG Editor. -----Original Message----- From: Grein, Christoph (Fa. ESG) Sent: Tuesday, November 29, 2011 3:28 AM To: agent@ada-auth.org Subject: Draft 14: nonx vs. non-x This is not very important, but it makes searching for a certain word (depending on the quality of the tool) uncomfortable if you have to search for some term like non-null also in the form nonnull. I would not have sent this in to you, but seeing that "otherwise" was replaced by "otherwise," throughout the manual, I dare send it in. This is a complete list of all terms appearing as both, nonxxx and non-xxx. At the end, there is a list of additional terms appearing on only one of these forms. Do with this list whatever you like. ------------------------ nonabstract 3.9.1(4.h/2), 3.9.3(6/2, 9.a, 9.b, 13, 16), 3.9.4(6.b/2, 19/2), 6.1.1(16/3), 7.3(16.a/3) non-abstract 3.9.3(4/3, 8.c/3, 9.h/2, 10.a, 10.c), 3.9.4(26/2), 9.1(9.2/3), 9.4(11.1/3), 12.5.1(27.b), 13.11(31) nonbinary 3.5.4(7.a, 27.1/1, 29, 29.a.1/2, 29.b, 29.c), 4.5.3(11.a), 13.7(25.a) non-binary G.2.3(27.c) nonconfirming 9.10(1/3), 13.1(24/2, 25/2, 26/2, 27/2), 13.3(32/2, 32.1/2, 32.a/2, 56.3/2, 56.d/2) non-confirming 13.1(15.b.1/3, 29.q/3) noncontiguous 3.5.5(8) non-contiguous 3.2.4(18.a/3), 13.5.2(31.d/2) noncontrolled 7.6(20/3) non-controlling 3.10(26.c/2), E.2.2(14/3) nondefault 13.3(8.1/3), 13.5.1(10.1/2, 13.2/3, 31.d/2), 13.5.2(2/2, 3/2, 4/2, 5.c/2, 7, 8/2, 8.a/2, 8.b/2, 9.b/2) non-default 13.1(13.d/2) nonderived 3.4(38.a, 38.b), 3.5.10(2/1), 7.6.1(11.1/3), 13.11.3(6/3) non-derived 10.2.1(15.4/3, 15.5/3, 28.n/3), 13.11(15), C.5(5) nondeterministic 4.9(38.b) nondeterminism 9.7.4(9.b) non-determinism 11.6(2.a) nondiscriminant 3.4(12), 4.4(15.a), 4.6(41, 54/1) non-discriminant 3.10.2(7.c/2), 13.13.2(9.1/3) non-discriminant-dependent 3.10.2(26.d) non-discriminated 3.2(9.a) nondispatching 3.9(2.a), 3.9.2(11.a/2, 20.e/1, 24.b/2), 3.9.3(1.a, 6.f/2, 7), 6.1(33), 6.4(31.d/2), 12.5.1(23.c/2) non-dispatching 13.13.2(27.a/2) nonempty 9.5.3(24.e), A.17(31/2), A.18.4(6/2), A.18.6(58/3), A.18.7(6/2), A.18.9(81/3), D.2.1(6/2), D.2.3(9/2, 11/2), D.4(12) non-empty A.4.3(56.e/3), A.16(131.d/3), A.18.2(135.a/3, 237/3), A.18.3(151/3)), A.18.4(55.n/2), A.18.18(39/3), A.18.30(17/3), D.2.2(6.2/3), D.2.6(21/2) nonexistent 3.9.3(8.a), 10.2(34.c), 13.9.1(13/3), 13.11(16/3, 16.b/3) non-existent 3.9.2(1.a.1/2), A.16(61/2), A.18.2(252.b/3), A.18.3(157.c/3), A.18.4(80.c/3), A.18.7(101.c/3), A.18.10(227.a/3), A.18.18(70.a/3) nonfirst 13.1(14.a) non-first 13.11(3.a) nonformal 3.2.3(7/2), 12.5(8.a/2, 9), J.4(2) non-formal 3.7(10.b/3), 3.10.2(32/3), 4.9(38.e/2), 7.5(8.4/3), 12.5.1(5.e/3) nongeneric 3.7(26.a/2), 5.4(10.c/3), 7.2(6, 15.d), 10.1.1(19.a), 12(1, 1.a, 3), 12.2(1, 1.a), 12.4(12.b, 12.c, 12.d), A.5(1), A.5.1(1, 9/1, 9.a, 48, 48.c, 48.i/2), A.7(4/2), A.10.8(20, 22, 23), A.10.9(32, 34, 37), A.11(2/2, 3/2), G.1(1), G.1.1(25/1, 25.a, 25.b, 54, 58.c, 58.h/2), G.1.2(9/1, 9.a, 21, 46, 49.c, 49.g/2), G.1.3(9.1/2, 9.a/2, 35.a/2), G.3(1/2), G.3.1(31/2, 31.a/2, 87/2, 91.b/2), G.3.2(53/2, 156/2, 161.b/2) non-generic 6.2(6) non-generics 6.3(11.e) nongeneric-formal 12.5(1.a) nongraphic 3.5(27.5/2, 39.4/3, 39.a.2/2, 56.1/3, 59, 63.i, 63.l/3), 3.5.2(2/3, 9.o/3), A.1(56.l/3) non-graphic 3.5(63.m/3), 3.5.2(9.h/2, 9.i/3)) noninherited 3.7.2(12/3), 4.3.1(11.a), 6.4(10.e/2) non-inherited 9.1(9.e/2), 9.4(11.e/2), 10.2.1(11.4/3), J.15.8(8/3) noninterruptible D.3(14.a) non-interrupt D.3(16.c) nonintrinsic 3.10(13/2) non-intrinsic 3.10.2(1) nonlibrary 7.2(4.b, 5), 10.1.1(28) non-library 8.3(29.i) non-library-level 3.9(12.a/2), 13.11.4(23/3, 25/3, 27.b/3) nonlimited 3.2(10/2, 10.d/2, 12/2, 13.a.1/2), 3.2.1(16.c/2), 3.4(4.b, 5.h/2, 5.i/3, 8/2, 17/2, 17.c, 17.d/2), 3.6.2(15), 3.6.3(5), 3.7(1.d/2, 9.1/3, 9.d/3, 10.e/2, 10.f/2, 10.f.2/3), 3.7.2(3.a/3, 3.b/3), 3.8(24), 3.9(9.a, 23.a/2), 3.9.1(3/2, 3.a, 3.9.1(4.h.1/2), 3.9.4(12/2, 19/2), 3.10(9.b, 9.f/2, 9.l/2, 26.e/2), 4.3(6.c), 4.5.2(1, 1.a, 9.8/3, 32.1/1), 4.5.3(3), 4.8(5.f/3, 20.o/3), 5.2(5/2, 28.f), 6.1.1(20/3, 22.a/3), 6.2(10.g), 6.5(21.b/2, 28.h/2), 7.2(1.b, 6/2, 7.j), 7.3.1(5.1, 7.u, 12/2), 7.5(1/2, 1.c/2, 1.d/2, 2.a.1/2, 2.a, 2.b, 6.b/2, 6.c/2, 6.d/2, 7, 8.b/3, 8.c/3, 9.a/2, 16, 16.a, 16.b, 16.c), 7.6(2, 9.a, 16/3, 18.b/3, 22/2, 27.a/2, 27.g/2), 7.6.1(24, 24.b), 8.4(5/2), 8.5.3(3.a.1/2), 9.1(9.d/2), 9.4(11.d/2), 9.6(5), 9.8(12.a), 10.2.1(17.e/2, 25.1/2, 28.e/2), 12.3(11.a/2, 11.q, 11.bb, 11.dd/1, 11.jj), 12.5(7.c/2), 12.5.1(1/3, 5.1/3, 5.f/3, 17/2, 25, 28.i/3), 13.7(34/2, 34.c), 13.13.2(40/2, 46/2, 54/1), A.18(5.c/2, 5.d/2, 5.e/2, 5.f/2, 5.g/2, 5.h/3, 5.i/3, 5.i.1/3, 5.i.2/3, 5.i.3/3, 5.i.4/3, 5.s/2), A.18.2(235.a/2), A.18.25(5.a/2), E.2.2(8.b/2, 19/3) non-limited 3.4(38.m/3), 3.7(37.e/2), A.18.2(88.b/3) nonlimitedness 7.5(6.c/2) nonnegative 9.6.1(44/2), 13.3(23/2, 25/2, 26/2, 26.4/2, 38.l, 41, 48, 58.a, 70, 70.a), 13.5.1(10), 13.12(6), 13.13.2(1.5/2, 9.2/3), A.5(12), A.5.3(57), A.10.6(4), A.10.8(2), D.14.2(14/2), G.1.1(34, 47, 58) non-negative F.3.2(19) non-positive D.14.2(21/3) nonnull 3.2(6.b, 9.b), 3.5(57), 4.5.2(26/3, 34), 4.5.3(14.d), 4.6(38, 38.a), 13.11.3(6.2/3), 13.13.2(35.c/3), D.5.2(8) non-null 3.2(9.a), 3.4(27.a/2), 3.9.2(20.a.3/3), 3.10(13/2), 4.5.2(30.3/3), 4.9(44.v/2), 10.2.1(9.b, 11.c/3), 13.11.2(17.1/3, 17.a.1/3, 17.b), A.16(82/3, 104.a/2), C.7.3(9/2), D.14.1(12/2), D.15(9/2) nonoverloadable 3.5.2(3.a/2), 8.4(16.d) non-overloadable 1.1.2(26.b), 8.3(6.a, 26.i), B.2(9.a) non-overloading 8.6(2) nonportable Introduction 41/2, 6.4.1(18.d/3), 11.5(31.j/2), 11.6(6.g) non-portable 1.1.5(12.a), A(2.b) nonportabilities 3.5.4(36.h) non-portabilities 1.1.5(12.c) nonportability 4.6(33.a/2), 9.10(15.b) non-preelaborable 10.2.1(9.b, 10.a.1/2, 27) non-preelaborated 10.2.1(11/3, 11.a.1/1, 27.a/1) non-PI (non-preelaborabe initialization) 10.2.1(28.r/3) nonpreemptible D.3(14.a) nonpreempting D.5.1(14) non-preemptive D.2.4 (title), D.2.4(1/2, 2.a/3, 3.a/2), D.2.6(2.b/2) nonprivate 3.4(17.b, 38.a, 38.b), 3.8(31.c), 7.4(14.h), 7.5(16.b), 12.5(7.c/2) non-private 10.1.2(5.a/2), 10.2.1(11.c/3), A.4.5(75) nonscalar 3.5(63.a/1), 4.9(1.d), 13.9(11/2, 11.a/2, 11.a.2/2), 13.9.1(6.1/2) non-scalar 3.2.3(8.a) nonstatic 4.3.3(17/3, 17.a, 29.a), 4.9(3.a, 10.b, 38/2, 44.p, 44.v/2), 4.9.1(1.3/2, 1.4/2), 5.4(10.b, 10.c/3), 6.4.1(6.10/3, 6.20/3), 10.2.1(10.2/2, 10.3/2), 12.3(14.c), 12.4(9/2), 12.6(9), 13.1(22, 22.h, 29.f), 13.3(48.m), 13.14(1.o, 8/3) non-static 3.2.4(18/3), 4.3.1(31.e/3), 13.3(56.b.1/3) nonterminal 1.1.4(15), 9.1(32.c) non-terminal 4.5.7(7.k/3) nonvolatile 9.10(9.c) non-volatile C.6(24.d/3) nonzero 3.5(27.6/2), 3.6.2(1), 4.5.4(3), 6.5(21.q/3), 13.1(24/2), 13.3(26.3/2), A.5.2(54), A.5.3(3, 4, 9, 10, 16, 26.b, 47, 53, 53.a, 59.a), A.10.6(6), A.10.8(8), A.10.9(2, 19, 24), A.18.2(228.b/2), C.6(22/2, 22.a/2), G.1.1(50), G.1.3(15.1), G.2.2(4.a) non-zero 10.2.1(15.d/2), D.14(13.a/2), F.3.2(10) ----------------- non-access 6.1(26, 28/2) nonactive 10.2(28.a) non-Ada D.4(15.a.2/2), H.4(20.a) nonaddressable 13.1(24/2) non-aliased 6.8(5.a/3), D.5.2(3/2) non-array 3.2(9.a), 3.4(8/2), 4.1.2(7), 4.5.2(17), 4.6(40), 5.2(11.a), 7.3(9.b), 13.5.2(1) nonblocking 9.5.1(18) nonboolean 13.4(8, 8.a) non-breaking A.1(49/2) nondecreasing D.8(18.a) non-discrete 4.1.4(9.b/3) nondistributed E(7), E.2(1), E.2.1(8.a) non-edited F.3(19/2) non-elaborable 3.1(11.f) non-English J.2(5.a) nonenvironment 10.2(8.a) nonequivalent A.18.8(66.1/3), A.18.9(79.1/3) non-evaluable 3.1(11.f) non-executable 13.3(13.a) non-fixed H.3.1(15) non-governmental Foreword 1/3 non-held D.11(13) non-imported 7.4(10.a/3) non-incomplete 3.9.2(13.d/2) noninstance 7.2(5), 10.1.1(16.b, 16.c, 16.d), 13.14(3/3) non-interface 3.9(2.1/2), 3.9.1(1/2), 12.5.1(5.e/3) non-language-defined A.2(4.b) nonnested 10.2.1(18.a/2) non-obvious 1(2.a/3) non-optional B(1.a) non-others 3.8.1(15/3), 5.4(7/3) nonoverlapping 9.10(1/3, 1.d/3), A(3/2), A.4.3(64), C.6(8.a/3, 8.b/3) non-overridable 8.3(10.a/1, 26/2) nonpathological D(4) non-per-object-expression 3.3.1(18.a) non-primitive 4.5.2(9.c/2), 8.5.4(12) non-protected 3.10.2(10/1) non-record 4.5.2(24.a/3, 32.a.1/3) non-redundant 1(2.d/3) nonreentrant E.5(24.a) non-remote 13.13.2(52/3, 52.a/3) non-reserved C.3(2, 18) non-returning 6.5.1(title), 6.5.1(3.2/3, 3.4/3, 4.a/2, 4.b/3, 5/2, 6/2, 6.a/2, 7/2, 9/2, 9.b/2, 9.c/2) non-root 10.1.2(6.a) non-semantic 1.1.2(39.j/2, 39.w/2, 39.jj/3) nonstandard 1.1.5(11), 2.3(6, 6.g/3). 3.5.2(9.n/3), 3.5.4(14.b, 26, 26.a), 3.5.6(8, 8.a), 12.5.2(8, 8.a), A.2(4.c), A.3.2(60.f/3), D.1(29/3) nonstring 4.9(1.d, 24.b/3) non-stub E.2.3(17.a/1) nonsubpool-supporting 13.11.4(32.c/3) non-synchronized 7.5(8.c/3) non-syntax 6.4(3.a/3) non-technical 1.1.4(16.b) non-terminated C.7.2(20/2) non-terminating D.7(15.1/2) nontextual 10.1(2.b) non-trivial 4.8(10.d/2), 13.11(26), 13.11.4(35/3) non-unchecked-union B.3.3(26/2) nonuniformity 11.5(31.e) non-universal 3.3.2(10.a) non-variant 13.5.1(31.c) non-visible 10.2.1(15.3/2, 15.6/3) non-void B.3(65) **************************************************************** From: Bob Duff Sent: Tuesday, November 29, 2011 2:17 PM > Christoph Grein (channeling Gary) sent the following lengthy list of > terms that are inconsistently used in the Standard. Christoph Grein, eh? It just so happens that right now I'm working on a GNAT bug reported by Christoph Grein. And when I fixed it, I caused a regression in another Christoph Grein bug. And when I fixed THAT, .... It's like Whack-a-Mole. Christoph Grein is apparently the only person on the planet who makes heavy use of the Ada 2005 rules for abstract operators of untagged types. Or is that nontagged types? ;-) > My initial reaction is to change those that are different only in AARM > notes (as that is relatively easy and doesn't require detailed > tracking of the changes). But changing normative wording requires a > lot more work and deciding which form is better -- two things I'd > rather avoid. So I'm not planning to make any changes there. I think the editor should be allowed to make minor editorial changes like these without horsing around with tracking changes. Seems like a global search and replace would be simpler. I also think the editor should be allowed to say "too much work; forget it". Anyway, I suggest you don't bother making any changes unless you're going to change the RM as well as the AARM. After all, the RM is more important. I think English is evolving to use fewer hyphens. See here: http://www.copydesk.org/conference/2011/sessions/the-ap-stylebook-editors-visit-aces-2011/ where the AP decided to replace "e-mail" with "email". (I use both. Hobgoblins, and all...) If you do decide to change things, "non-" should be changed to "non" in almost all of the cases listed. The exceptions are: When "non-" prefixes something that already has a dash, I think you should keep the dash: non-discriminant-dependent non-library-level non-language-defined non-per-object-expression non-unchecked-union nonsubpool-supporting And the following seem like made up words, so "non-" feels right to me: non-PI non-Ada non-access non-aliased non-array non-English **************************************************************** From: Robert Dewar Sent: Tuesday, November 29, 2011 2:27 PM I think it is a pointless waste of time to worry about this, or more precisely to spend any time over it. If you like just put a note somewhere that in the standard non-xxx means the same as nonxxx and be done with it. It really is a total waste of resources to look for these in the first place, and most certainly for us to spend time and money "fixing" them). **************************************************************** From: Randy Brukardt Sent: Tuesday, November 29, 2011 2:36 PM ... > Anyway, I suggest you don't bother making any changes unless you're > going to change the RM as well as the AARM. After all, the RM is more > important. My main concern was places where there are a few (usually new) AARM notes that use an inconsistent spelling from the rest of the RM. (Examples: "non-contiguous", "non-graphic", "non-limited" Where the RM is wildly inconsistent all over, it doesn't seem worth the work. (Consider the uses of "nonabstract" and "non-abstract" in that category.) I note that there are a couple of cases where there is one new normative use and a couple of notes with one spelling, and many uses of the other spelling. (For instance, "non-static"). I suppose these also should be fixed, as the new uses ought to be considered wrong. I think virtually anything I could be doing (including watching football ;-) would be a better use of my time than changing 16 occurrences of "non-null" to "nonnull". **************************************************************** From: Bob Duff Sent: Tuesday, November 29, 2011 2:44 PM > I think it is a pointless waste of time to worry about this, or more > precisely to spend any time over it. I won't argue with that! >...If you like just put a note > somewhere that in the standard non-xxx means the same as nonxxx and >be done with it. I suggest you don't even bother to do that. Everybody already understands that non-xxx means nonxxx means "not xxx". And why advertise our lack of consistency? **************************************************************** From: Bob Duff Sent: Tuesday, November 29, 2011 2:48 PM > I think virtually anything I could be doing (including watching > football ;-) would be a better use of my time than changing 16 occurrences of "non-null" > to "nonnull". OK, so go watch a game, and don't worry about the non-important non-issue of "non-" vs. "non". ;-) **************************************************************** From: Robert Dewar Sent: Tuesday, November 29, 2011 3:01 PM > I think the editor should be allowed to make minor editorial changes > like these without horsing around with tracking changes. Seems like a > global search and replace would be simpler. > > I also think the editor should be allowed to say "too much work; > forget it". I agree. I care 0.00% about what is or is not gramatically correct here, but I am a bit sympathetic to the searching argument. Why not do a global replace of "non-" by "non" and be done with it. **************************************************************** From: Robert Dewar Sent: Tuesday, November 29, 2011 3:08 PM > I think virtually anything I could be doing (including watching > football ;-) would be a better use of my time than changing 16 occurrences of "non-null" > to "nonnull". Surely a simple global replace of non- to non is close to zero work? **************************************************************** From: Randy Brukardt Sent: Tuesday, November 29, 2011 3:49 PM I'm not sure that this would qualify as an "insignificant" change vis-a-vis the various copyrights on the Standard, and as such would prefer to have the changed paragraphs marked. (Recall that the "/3" paragraph markers serve to meet the requirements of the Intemetrics copyright that "alterations are clearly marked as alterations", as well as the purpose of marking changes for references.) There have been a few instances of corrections that aren't marked (mostly changed capitalization), but these were all changes that could not be construed to change the meaning. In addition, Bob gave a short list of words that shouldn't be changed (with which I agree) and I wouldn't want to change all of those by accident or on purpose. So it would take a number of such replacements. If the ARG directs me to make a "silent" change here, I'd do it, but I'm not going to do that without that direction. **************************************************************** From: Bob Duff Sent: Tuesday, November 29, 2011 4:38 PM > I'm not sure that this would qualify as an "insignificant" change > vis-a-vis the various copyrights on the Standard, and as such would > prefer to have the changed paragraphs marked. (Recall that the "/3" > paragraph markers serve to meet the requirements of the Intemetrics > copyright that "alterations are clearly marked as alterations", ... I wrote that copyright notice (although it got modified by some lawyers in some meaningless way). I think you can fulfill it by a blanket "We fixed some typos and grammatical errors." You really don't need to attach a change-mark to every pixel that looks different. >... as well as the purpose of marking changes for references.) There >have been a few instances of corrections that aren't marked (mostly >changed capitalization), but these were all changes that could not be >construed to change the meaning. Surely changing "non-existent" to "nonexistent" could not be construed to change the meaning! > In addition, Bob gave a short list of words that shouldn't be changed > (with which I agree) and I wouldn't want to change all of those by > accident or on purpose. So it would take a number of such replacements. > > If the ARG directs me to make a "silent" change here, I'd do it, but > I'm not going to do that without that direction. Your call. I don't care if you make the changes or not, but if you do, I don't want any change-tracking on it. **************************************************************** From: Robert Dewar Sent: Tuesday, November 29, 2011 4:58 PM > I'm not sure that this would qualify as an "insignificant" change > vis-a-vis the various copyrights on the Standard, and as such would > prefer to have the changed paragraphs marked. Seems an overwrought concern to me. Well in that case do absolutely nothing, not one single instance should be changed if you think you have to mark paragraphs as a result, it's just a waste of your limited time, over a completely unimportant issue. **************************************************************** From: Jean-Pierre Rosen Sent: Tuesday, November 29, 2011 5:16 PM > I agree. I care 0.00% about what is or is not gramatically correct > here, but I am a bit sympathetic to the searching argument. Why not do > a global replace of "non-" by "non" and be done with it. Interesting. I was about to react the same way (just make a global search and replace), except that to my french eyes, "non-" looked better than "non"... I don't care too much which one is chosen, but I do have some sympathy for the consistency argument - especially when thinking of textual search in the RM. But certainly not at the cost of changing paragraph numbers. This would be highly confusing to the people wondering what has changed in the damn paragraph! **************************************************************** From: Robert Dewar Sent: Tuesday, November 29, 2011 5:26 PM Right, I am a bit disturbed to find that para numbers have been changed for other trivial matters like capitalization. **************************************************************** From: Randy Brukardt Sent: Tuesday, November 29, 2011 5:43 PM Not capitalization, but for major punctuation changes (semicolon to period, etc.) and for font changes (because the font of a term conveys semantic information in the Ada Standard: syntax vs. semantic terms vs. definitions (and recall there are places where the terms are defined in each category -- like "body" so the font is really significant). In any case, we discussed this back at the start of the Corrigendum work in 1999, and it would be weird to change course today. The hyphens in this case are right on the cusp of what I'd consider significant -- which is the main reason that we're having this discussion in the first place. It could go either way, which means that I want a clear direction to make the change without marking. (So far, we seem to have that direction, but there are many more people to hear from.) **************************************************************** From: Gary Dismukes Sent: Tuesday, November 29, 2011 6:27 PM I've resisted commenting till now (I have definite opinions about "non" vs. "non-";-), but since you'd like guidance, I'll cast a vote in favor of making the global change without marking paragraphs. **************************************************************** From: John Barnes Sent: Wednesday, November 30, 2011 6:18 AM I have been waiting to see which way Gary would go: Gary, I thought you just loved hyphens. My view is to do the global edit, take out the wretched hyphens and not change paragraph numbers. There is a lot of merit in being consistent for those who want to search for say nonlimited. It is a pain if you have to search for both forms. Hmmm. I had better check my book.... **************************************************************** From: John Barnes Sent: Wednesday, November 30, 2011 6:51 AM I just checked my book I found the following with hyphens non-graphic non-overloadable non-dispatching (7 times) non-returning non-square non-null non-blank non-integral non-variant non-negative non-Ada (non-Ada command language) Apart from non-dispatching only 1 or 2 uses in each case. I didn't find any of the above without hyphens but I didn't search very thoroughly for them. Apart from non-Ada, I would be happy to take out the hyphens. **************************************************************** From: Brad Moore Sent: Wednesday, November 30, 2011 9:55 AM I also think its worthwhile making the changes, if it can be done without having to mark paragraph numbers. I agree with John that searching for occurrences of a word can be misleading if one does not consider searching both with and without the minus sign. As for the changes, I could go either way, though I like Bob Duff's earlier suggestions for deciding on when to leave them in or take them out. On an aside, if we remove the minus signs, we would be non-minussed. If we leave them in, then would we be nonplussed? :-) **************************************************************** From: John Barnes Sent: Wednesday, November 30, 2011 1:12 PM > On an aside, if we remove the minus signs, we would be non-minussed. > If we leave them in, then would we be nonplussed? :-) Aagh! That's awful or awfully good! **************************************************************** From: Randy Brukardt Sent: Thursday, December 15, 2011 12:00 AM > > The hyphens in this case are right on the cusp of what I'd consider > > significant -- which is the main reason that we're having this > > discussion in the first place. It could go either way, which means > > that I want a clear direction to make the change without marking. > > (So far, we seem to have that direction, but there are many more > > people to hear from.) > > I've resisted commenting till now (I have definite opinions about "non" vs. > "non-";-), but since you'd like guidance, I'll cast a vote in favor of > making the global change without marking paragraphs. I hate to bring this up again, but once I make the changes without marking the paragraphs there will be no reasonable way to go back to the original version (considering all of the other changes that I'm making at more-or-less the same time). So I want to be 100% certain that there are no objections. It's clear that there is a strong consensus for making the change without marking any changes in the Standard. I'll make this change (really several hundred tiny changes) without marking the changes unless I hear from anyone that they object; I'll need to hear any such objections before Christmas (Dec. 25th). If there is any objection, I'll put it to a formal letter ballot. [Let the record show that no one responded to this message.] **************************************************************** From: Randy Brukardt Sent: Friday, December 23, 2011 12:59 AM The minutes contain the note: Remove hyphen from "run-time". This is a problem, as the Ada Standard consistently (except for a handful of AARM notes, probably changed by the hyphen police) spells this "run-time". The easiest place to see this is to look at the header for *any* Bounded Error: Bounded (Run-Time) Errors For the AARM, there are 16 "runtime"s, and 179 "run-time"s. It's no contest. (And that's not including Bounded Error headers.) Which now brings up the question: (1) Should I fix the 16 AARM notes (silently) to match everything else? (2) Or should I change 179 uses, *and* rewrite the program that generates the subheaders to support an alternative spelling? (This is clearly a lot more work, and a fairly visible change.) (3) Or should I forget I ever heard of this note and head to a holiday party?? **************************************************************** From: Ben Brosgol Sent: Friday, December 23, 2011 1:30 AM The general spelling rule is as follows, at least in American English: * When a two-word phrase appears as an adjective before the noun, use a hyphen. E.g., "run-time error" (or "two-word phrase" :-) * Otherwise do not use a hyphen. E.g., "the check is performed at run time". (The canonical example showing the rationale for hyphenating compound adjectives that precede the noun is "half-baked chicken" versus the potentially ambiguous "half baked chicken". There is no ambiguity, and thus no need for the hyphen, when the adjective follows the noun: "The chicken is half baked." And, naturally, there are exceptions to the rule (in some cases hyphens are never used, and in other cases hyphens are always used). :-) I personally find the one-word form "runtime" unnatural, both as as an adjective and as a noun; it sounds like compiler writer's jargon. From your message it looks like the ARM abides by the hyphenation conventions summarized above, and does not contain the "runtime" form. So the only question is what to do about the AARM. I don't have strong feelings except that it's not worth your spending a lot of effort on this issue. So I would vote for your alternative (3); have fun at the party :-) **************************************************************** From: Randy Brukardt Sent: Friday, December 23, 2011 2:16 AM > The general spelling rule is as follows, at least in American English: > > * When a two-word phrase appears as an adjective before the noun, use > a hyphen. E.g., "run-time error" (or "two-word phrase" :-) > > * Otherwise do not use a hyphen. E.g., "the check is performed at run > time". Humm, I would never write "run time", and certainly not in the Standard. That should be "execution" or "evaluation" rather than an informal term. That is, "the check is performed during evaluation of the expression". Whenever I use "run-time" or "runtime", I'm referring to the "run-time library" that underlies every language translator. Most of the contexts where the term is used are talking about that. > (The canonical example showing the rationale for hyphenating compound > adjectives that precede the noun is "half-baked chicken" versus the > potentially ambiguous "half baked chicken". There is no ambiguity, > and thus no need for the hyphen, when the adjective follows the noun: > "The chicken is half baked." And, naturally, there are exceptions to > the rule (in some cases hyphens are never used, and in other cases > hyphens are always used). :-) > > I personally find the one-word form "runtime" unnatural, both as as an > adjective and as a noun; it sounds like compiler writer's jargon. "runtime" or "run-time" or "run time" in any form is compiler writer's jargon to me (I suppose because I'm a compiler writer). It's used (almost exclusively) as a short name for "run-time libraries". I prefer to avoid it altogether as much as possible if I'm writing for anyone other than compiler writers. (And I always spell that "runtime" in my writing, that's probably how it got into the AARM notes.) As noted above, I'd be much more likely to write "execution" or "evaluation" instead of "run time" when talking about "running" a program. But that's just me, there are about 80 "run time"s in the AARM, most of them in the form "at run time". I never even thought to look for it, since it's not something that I would write myself. > From your message it looks like the ARM abides by the hyphenation > conventions summarized above, and does not contain the "runtime" form. > So the only question is what to do about the AARM. I don't have > strong feelings except that it's not worth your spending a lot of > effort on this issue. So I would vote for your alternative (3); have > fun at the party :-) Well, the real problem here is that I misinterpreted the note "remove the hyphen". There is two possible meanings for that: "remove the hyphen" (jamming the words together), and "remove the hyphen" (replacing it with a space). Well, actually, there is only the first meaning, but people at ARG meetings usually say the first and mean the second -- which is OK if it is unambiguous but that rarely is the case. (And when in my "Editor" mode, I tend to think very literally, because I can never figure out what is meant otherwise. **************************************************************** From: Robert Dewar Sent: Friday, December 23, 2011 4:01 AM > (1) Should I fix the 16 AARM notes (silently) to match everything else? > > (2) Or should I change 179 uses, *and* rewrite the program that > generates the subheaders to support an alternative spelling? (This is > clearly a lot more work, and a fairly visible change.) > > (3) Or should I forget I ever heard of this note and head to a holiday > party?? I favor (3). The hyphen issue is spectacularly unimportant. It is deefinitely not worth while spending significant effort for (2), and really who cares if the AARM has hyphens here or not? I suppose fixing the 16 notes is easy enough, but only if done without a lot of time-wasting discussion. **************************************************************** From: Tullio Vardanega Sent: Friday, December 23, 2011 12:35 PM I consider myself a member of the hyphen police and always hated the abuse of "runtime". That said, however, I would certainly recommend the editor to go (3). **************************************************************** From: Bob Duff Sent: Friday, December 23, 2011 2:31 PM > The minutes contain the note: > > Remove hyphen from "run-time". I suspect this was referring to some particular paragraph! Without seeing the para, I can't tell whether it's correct to change it to "run time". Changing "run-time" to "run time" globally would be wrong. Changing it to "runtime" would be even wronger; "runtime" is not a word. (OK, "wronger" isn't either, but I don't care; this ain't the RM. ;-)) > This is a problem, as the Ada Standard consistently (except for a > handful of AARM notes, probably changed by the hyphen police) spells this "run-time". > > The easiest place to see this is to look at the header for *any* > Bounded > Error: > > Bounded (Run-Time) Errors That's correct as is; please don't change it. > For the AARM, there are 16 "runtime"s, and 179 "run-time"s. It's no contest. > (And that's not including Bounded Error headers.) > > Which now brings up the question: > > (1) Should I fix the 16 AARM notes (silently) to match everything else? Only if you inspect each one, and change it to either "run-time" or "run time" as appropriate. A waste of time, but not wrong. Ben gave the rules. > (2) Or should I change 179 uses, *and* rewrite the program that > generates the subheaders to support an alternative spelling? (This is > clearly a lot more work, and a fairly visible change.) Certainly not! > (3) Or should I forget I ever heard of this note and head to a holiday > party?? Good idea! **************************************************************** From: Robert Dewar Sent: Friday, December 23, 2011 2:48 PM > Changing "run-time" to "run time" globally would be wrong. > Changing it to "runtime" would be even wronger; "runtime" is not a > word. What is your authority for such a claim. Most modern online dictionaries recognize this as a standard computer term. It is true that runtime is not in the OED edition 2, but then neither is run-time. In English you can't go adding hyphens between arbitrary words, the allowed hyphenated forms are included int he dictionary. So run-time is just as much a made up word as runtime. Over time, hyphens tend to disappear, I see no reason not to hasten the process with runtime On Google "run-time" has 45.6 million hits, and runtime as 169 million hits, so Bob, I think you are fighting one of those hopeless rearguard actions against modern usage here (*). (*) Like my hopless wish to rescue disinterested, moot, and oxymoron, all lost causes. **************************************************************** From: Bob Duff Sent: Friday, December 23, 2011 3:21 PM > > Changing "run-time" to "run time" globally would be wrong. > > Changing it to "runtime" would be even wronger; "runtime" is not a > > word. > > What is your authority for such a claim. Ken Dritz. And more recently, Ben Brosgol. > you can't go adding hyphens > between arbitrary words, the allowed hyphenated forms are included int > he dictionary. I don't see "half-cooked" in the dictionary, but Ben says I can say "half-cooked chicken" (which is an entire chicken, only half cooked). > (*) Like my hopless wish to rescue disinterested, moot, and oxymoron, > all lost causes. Yup. ;-) I haven't given up on "disinterested", though. It's an important word. **************************************************************** From: Robert Dewar Sent: Friday, December 23, 2011 3:31 PM > Ken Dritz. And more recently, Ben Brosgol. People just pass on rules they hear from others all the time, but the question is, where did the original rule come from, and does it have any validity given that we are talking technical terminology, where the sole criterion should be current usage. ... >> (*) Like my hopless wish to rescue disinterested, moot, and oxymoron, >> all lost causes. > > Yup. ;-) > > I haven't given up on "disinterested", though. > It's an important word. Trust me, it's a lost cause. Interesting that it has no antonym, so you have to say something like "As a chief lobbyist for the drug manufacturers, he was not disinterested in the pending legislation restricting lobbying activities". **************************************************************** From: Ben Brosgol Sent: Saturday, December 24, 2011 12:52 AM > What is your authority for such a claim. Most modern online > dictionaries recognize this as a standard computer term. It is true > that runtime is not in the OED edition 2, but then neither is > run-time. In English you can't go adding hyphens between arbitrary > words, the allowed hyphenated forms are included int he dictionary. So > run-time is just as much a made up word as runtime. I don't see "French-language" as a hyphenated form in the dictionary, but the hyphen is important in the phrase "French-language student" to avoid ambiguity. Likewise my earlier example of "half-baked chicken". The situation with "run time" is not as obvious, and as an invented term it could be spelled with either the hyphenated or nonhyphenated form when used as an adjective before a noun. Still I find "run-time library" preferable to "run time library" since the hyphen avoids any possibility of confusion. Here's an example: "From training to run time libraries, Acme Compilers Inc does it best" There are conventions for when hyphens should or should not be used in a multiword phrase used as an adjective that precedes a noun. These conventions are perhaps different in American English and British English. > > Over time, hyphens tend to disappear, I see no reason not > to hasten the process with runtime > > On Google "run-time" has 45.6 million hits, and > runtime as 169 million hits, so Bob, I think you are > fighting one of those hopeless rearguard actions against > modern usage here (*). Perhaps we can blame Sun ("Java Runtime Environment") and Microsoft ("Common Language Runtime") for this abomination but in the Ada community we opt for readability rather than the saving of one keystroke :-) And if "runtime" comes, can "compiletime" be far behind? :-) **************************************************************** From: Robert Dewar Sent: Saturday, December 24, 2011 7:51 AM But the criterion should be exactly that "readability", and not what strikes one person as an abomination. Much of grammar is ruled by people's subjective tastes from arbitrary rules they have learned long ago. For example "between you and I", grates badly for many people who consider it wrong, but all the great authors, including Shakespeare have embraced this phrase for centuries, and the claim that it is wrong is just not sustainable. When it comes to runtime, surely readability is determined by usage and familiarity. It is obvious to me that runtime is far more familiar and hence more readable than run-time. Blame Sun and MS if you like for this state of affairs, but the clear fact of the matter is that more people are familiar with runtime, and I do not see that you can use readability as an argument for clinging to obsolete conventions of yesterday. Indeed, I would say if Sun and Microsoft so clearly establish this usage, what's the justification for Ada insisting on what is now an obsolete, or at best obsolescent usage. Language is not stationary, it moves, but people's grammatical taste tends to be much more reactionary. And the funny thing is tha so many of the treasured rules are almost completley arbitrary. For example the US distinction between that and which was fabricated out of whole cloth by Fowler in the early part of the 20th century, when he mused that it was a pity to have two words that meant the same thing, so why not create an artificial distinction. He then described what is now recognized US usage. Ironically, it never caught on in his native country. Similarly the distinction between shall and will, taught so slavishly still to many school children, is a whole cloth invention by a late 19th century grammarian (again from a starting point of "why have two words for the same thing?"). I find Google immensely useful in finding out what common usage really is, and if you are worried about readability, rather than adhering to some arbitrary set of grammatical rules, then going with common usage is the obvious path to improved readability IMO. > And if "runtime" comes, can "compiletime" be far behind? :-) Well compiletime is far behind so far. It's certainly not an unknown usage. Google shows 449,000 hits, but "compile time" gets far more hits (4,310,000). So for the moment I would opt for compile time. You may complain that this is inconsistent, but there is not, and never has been a rule requiring consistency in english usage or grammar. So Robert's vote is for removing all hyphens and uniformly replacing run-time by runtime. **************************************************************** From: Randy Brukardt Sent: Monday, December 26, 2011 4:58 PM I hate to ask, but what the heck is this supposed to mean? "Disinterested" means "not interested", nothing more or less. I've never seen nor heard any other meaning for it (including in the sentence above!). Perhaps I've never noticed this supposed change in meaning because the meaning I know fits just fine in the sentences in question? I realize that "dis" does not always mean "not" ('disgrunted' doesn't mean "not gruntled" for the obvious reason that "gruntled" is not a word), but I know of no other usage here. It's very different for "moot"; I don't think I've ever read the word used in any way other than to mean "irrelevant" (outside of Robert's messages and various dictionaries :-). Perhaps this is another case where the same word is somehow different depending on context. ("Insure"/"Ensure" drive me nuts that way.) **************************************************************** From: Bob Duff Sent: Monday, December 26, 2011 5:24 PM > I hate to ask, but what the heck is this supposed to mean? "Disinterested" > means "not interested", nothing more or less. No, "disinterested" means "unbiased". If you want "not interested", you should say "uninterested". A disinterested observer (of something-or-other) has no stake in the matter, and will neither gain nor lose no matter how something-or-other turns out. We can trust such a person to make fair decisions. If you and I have a dispute, and we want it fairly resolved, we would like a disinterested judge (as opposed to a judge who might make some money if one of us wins, or loses some money if the other wins). But we don't want an uninterested judge. > Perhaps this is another case where the same word is somehow different > depending on context. ("Insure"/"Ensure" drive me nuts that way.) Yeah, well, unfortunately, life insurance doesn't ensure that one continues to live, and health insurance doesn't ensure that one will be healthy, and car insurance doesn't prevent car-crashes. **************************************************************** From: Robert Dewar Sent: Monday, December 26, 2011 5:25 PM > I hate to ask, but what the heck is this supposed to mean? "Disinterested" > means "not interested", nothing more or less. I've never seen nor > heard any other meaning for it (including in the sentence above!). > Perhaps I've never noticed this supposed change in meaning because the > meaning I know fits just fine in the sentences in question? Disinterested and Uninterested are totally different! Disinterested means you don't have some stake in the outcome, Uninterested means you are not interested. A judge must be disinterested, but certainly not uninterested. So using them interchangably is definitely "wrong" usage, but usage evolves, and too many people don't know the difference for the useful difference to survive. There is no opposite of disinterested. So you have to say something like "he was not disinterested in the outcome of the transaction". If you say "he was interested in the outcome of the transaction", it's ambiguous! > I realize that "dis" does not always mean "not" ('disgrunted' doesn't > mean "not gruntled" for the obvious reason that "gruntled" is not a > word), but I know of no other usage here. Gruntled is a perfectly good word, meaning satisified. Fairly recent, first use 1926 as far as I can tell, but certainly it's a fine word. Never say "xxx is not a word" without looking it up, you will be surprised how many words that are not in your vocabulary are perfectly fine english words. > It's very different for "moot"; I don't think I've ever read the word > used in any way other than to mean "irrelevant" (outside of Robert's > messages and various dictionaries :-). You clearly have no contact with lawyers who still use the word in its proper form (arguable, undecided). A moot point in law is one which you need not address because its resolution is not needed for the current case, so it is left undecided. It's easy to see how this morphs into irrelevant, but there is a real distinction. You can even here some one saying "That's a moot point at this stage, we already decided it this morning" :-) > Perhaps this is another case where the same word is somehow different > depending on context. ("Insure"/"Ensure" drive me nuts that way.) Most americans don't make the difference between insure and ensure, but british usually do "you must ensure that your house is properly insured". **************************************************************** From: Randy Brukardt Sent: Monday, December 26, 2011 5:39 PM > No, "disinterested" means "unbiased". If you want "not interested", > you should say "uninterested". A disinterested observer (of > something-or-other) has no stake in the matter, and will neither gain > nor lose no matter how something-or-other turns out. We can trust > such a person to make fair decisions. OK, thanks. (Re?)learn something every day. I suspect if you mean "unbiased" you ought to say "unbiased" -- less chance for confusion, and shorter as well. Some words are just too subtle when it is important to be clear... **************************************************************** From: Robert Dewar Sent: Monday, December 26, 2011 5:54 PM > I suspect if you mean "unbiased" you ought to say "unbiased" -- less > chance for confusion, and shorter as well. Some words are just too > subtle when it is important to be clear... No, unbiased does not mean the same thing. For example, a judge could be biased against women, and tend to rule against them, but he can still perfectly well be disinterested in the outcome of a particular trial in which a woman is involved. **************************************************************** From: Brad Moore Sent: Monday, December 26, 2011 7:04 PM Use of such words with subtle meanings can discombobulate the reader. Having a dictionary close at hand can help combobulate /(re-combobulate?) the reader. Another example of a word without an antonym, although apparently some online dictionaries now define combobulate as a word, which does suggest that the language is changing, for better out worse. **************************************************************** From: Ben Brosgol Sent: Monday, December 26, 2011 11:49 PM Long ago I remember seeing "INFLAMMABLE" on the sides of gasoline trucks, but that was replaced by its synonym, "FLAMMABLE". Apparently some thought that the "in" prefix on an adjective meant "not", as it does in most contexts. ****************************************************************