Version 1.1 of ai05s/ai05-0293-1.txt

Unformatted version of ai05s/ai05-0293-1.txt version 1.1
Other versions for file ai05s/ai05-0293-1.txt

!standard 1.1.3(1/2)          12-02-15 AI05-0293-1/01
!class presentation 12-02-15
!status work item 12-02-15
!status received 11-xx-xx
!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-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, ...<repeat>.  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 look
s 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.

****************************************************************

Questions? Ask the ACAA Technical Agent