Version 1.3 of ai05s/ai05-0092-1.txt

Unformatted version of ai05s/ai05-0092-1.txt version 1.3
Other versions for file ai05s/ai05-0092-1.txt

!standard 3.3.1(20.4/2)          08-05-28 AI05-0092-1/02
!standard 6.3.1(21.1/2)
!standard 13.13.2(55/2)
!standard 13.13.2(56/2)
!standard G.2.2(11)
!class presentation 08-03-05
!status work item 06-03-05
!status received 06-02-13
!priority Low
!difficulty Easy
!qualifier Omission
!subject More presentation issues in the Standard
!summary
This AI corrects minor errors in the Standard.
1) Drop "must" from 3.3.1(20.4/2) (two places).
2) Replace "must be" with "is" in 6.3.1(21.1/2).
3) Drop "must" from 13.3(8.1/2).
4) Replace "must" by "shall" in 13.13.2(55-56/2).
5) Replace "Safe_last" by "Safe_Last" in G.2.2(11).
!question
1) Generally, "must" shall not be used in normative rules of the standard. However, 3.3.1(20.4/2) uses "must precede" twice. Should this be fixed? (Yes.)
2) "Must" also occurs in 6.3.1(8.1/2). Fix that, too? (Yes.)
3) "Must" also occurs in 13.3(8.1/2). Should that also be fixed? (Yes.)
4) "Must" also occurs in 13.13.2(55-56/2). Sigh. More text to fix? (Yes.)
5) "Safe_last" should be written as "Safe_Last" in G.2.2(11). Fix it? (Yes.)
[Other questions here.]
!recommendation
(See summary.)
!wording
1) Drop "must" from 3.3.1(20.4/2); it occurs in two places.
2) Replace "must be" with "is" in 6.3.1(21.1/2).
3) Drop "must" from 13.3(8.1/2).
4) Replace "must" by "shall" in 13.13.2(55-56/2).
5) Replace "Safe_last" by "Safe_Last" in G.2.2(11).
!discussion
1) 3.3.1(20.4/2) uses "must precede", while 3.3.1(20.1-3/2) use "is preceded by". "Must" doesn't add anything here, as this is a rule after all -- following it is not optional and we don't need to re-enforce that.
2) 6.3.1(21.1/2) is a definition, and should use "is", not "shall" (or "must").
3) 13.3(8.1/2) is also a definition, and "must" is just emphasis.
4) 13.13.2(55/2) is an Implementation Requirement, and must use "shall". 13.13.2(56/2) is an Implementation Permission, so "shall" is optional, but just dropping "must" doesn't make much sense (the emphasis is needed).
5) All other references to Safe_Last use a capital 'L', this one should, too. Note that this error dates all the way back to the original Ada 95 Standard.
!corrigendum 3.3.1(20.4/2)
Replace the paragraph:
by:
!corrigendum 6.3.1(21.1/2)
Replace the paragraph:
by:
!corrigendum 13.3(8.1/2)
Replace the paragraph:
A machine scalar is an amount of storage that can be conveniently and efficiently loaded, stored, or operated upon by the hardware. Machine scalars consist of an integral number of storage elements. The set of machine scalars is implementation defined, but must include at least the storage element and the word. Machine scalars are used to interpret component_clauses when the nondefault bit ordering applies.
by:
A machine scalar is an amount of storage that can be conveniently and efficiently loaded, stored, or operated upon by the hardware. Machine scalars consist of an integral number of storage elements. The set of machine scalars is implementation defined, but include at least the storage element and the word. Machine scalars are used to interpret component_clauses when the nondefault bit ordering applies.
!corrigendum 13.13.2(55/2)
Replace the paragraph:
If Constraint_Error is raised during a call to Read because of failure of one the above checks, the implementation must ensure that the discriminants of the actual parameter of Read are not modified.
by:
If Constraint_Error is raised during a call to Read because of failure of one the above checks, the implementation shall ensure that the discriminants of the actual parameter of Read are not modified.
!corrigendum 13.13.2(56/2)
Replace the paragraph:
The number of calls performed by the predefined implementation of the stream-oriented attributes on the Read and Write operations of the stream type is unspecified. An implementation may take advantage of this permission to perform internal buffering. However, all the calls on the Read and Write operations of the stream type needed to implement an explicit invocation of a stream-oriented attribute must take place before this invocation returns. An explicit invocation is one appearing explicitly in the program text, possibly through a generic instantiation (see 12.3).
by:
The number of calls performed by the predefined implementation of the stream-oriented attributes on the Read and Write operations of the stream type is unspecified. An implementation may take advantage of this permission to perform internal buffering. However, all the calls on the Read and Write operations of the stream type needed to implement an explicit invocation of a stream-oriented attribute shall take place before this invocation returns. An explicit invocation is one appearing explicitly in the program text, possibly through a generic instantiation (see 12.3).
!corrigendum G.2.2(11)
Replace the paragraph:
Finally, S'Safe_First and S'Safe_last are set (in either order) to the smallest and largest values, respectively, for which the implementation satisfies the strict-mode requirements of G.2.1 in terms of the model numbers and safe range induced by these attributes and the previously determined values of S'Model_Mantissa and S'Model_Emin.
by:
Finally, S'Safe_First and S'Safe_Last are set (in either order) to the smallest and largest values, respectively, for which the implementation satisfies the strict-mode requirements of G.2.1 in terms of the model numbers and safe range induced by these attributes and the previously determined values of S'Model_Mantissa and S'Model_Emin.
!ACATS test
None needed.
!appendix

From: Tucker Taft
Sent: Wednesday, February 13, 2008  10:04 PM

A document by Derek Jones indicated that the Ada 2005
standard had 22 occurrences of "must."  Needless
to say that surprised me.  So I did a search.
I found the following 14 "musts":

   3.3.1(20.4)
   3.9.4(26/2), 3.9.4(33/2) (both from an Example)
   6.3.1(21.1)
   7.5(9/2) (a Note)
   12.6(16.1)(a Note)
   13.3(8.1/2), 13.13.2(55/2), 13.13.2(56/2)
   C.7.2(30/2), C.7.2(32) ("must" is used in non-technical way)
   M(1/2), M.1(1/2), M.2(1/2), M.3(1/2)

I'm not sure where the other 8 could be hiding.
Only 9 of the above 14 are actually clear places
where "shall" should have been used instead.
The others are informal uses of "must."  We might
still want to purge them all, however, just to avoid
any confusion about what are the real requirements.

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

From: Robert A. Duff
Sent: Thursday, February 14, 2008  8:40 AM

What document by Derek Jones are you talking about?

I object to blindly changing "must" to "shall".  Eschew obfuscation.  Certainly
the ones in "Language Summary" and "Examples" and other informal places can
remain as is.

The two in 3.3.1(20.4) can be fixed by changing "must precede" to "precede",
which matches the style used in the immediately preceding paragraphs, and
I think matches the general style of "Dynamic Semantics", which says what
happens, not what "shall happen".

In 6.3.1(21.1), "must be" should be "is"; it's a definition.

In 13.3(8.1/2), I could tolerate changing "must include" to "shall include",
but "includes" would be just as good.

In 13.13.2(55/2), "must" should be "shall".

In 13.13.2(56/2), "must" should probably be "shall".

Annex M is informative, so should not use "shall".

None of this has the slightest effect on implementers or users; as usual in
such cases, I'm happy to take "!No Action".

I get 22 occurrences, by the way:

@ grep -i must rm.txt 
parts: a specification, containing the information that must be visible to
must name the library units it requires.
specifies a Boolean expression (an entry barrier) that must be True before the
capabilities of class-wide operations and type extension must be tagged, so
objects of a given type must be represented with a given number of bits, or
      requiring late initialization must precede the initial value evaluations
      occurring earlier in the order of the component declarations must
Queue must provide implementations for at least its four dispatching
Queue, the implementation of the four inherited routines must be provided.
21.1/1 each attribute_designator in one must be the same as the corresponding
      assignment operation must be an aggregate or function_call, and such
      aggregates and function_calls must be built directly in the target
      formal_abstract_subprogram_declaration must be dispatching calls. See
is implementation defined, but must include at least the storage element and
of one the above checks, the implementation must ensure that the discriminants
stream-oriented attribute must take place before this invocation returns. An
time must be completely deterministic. For such implementations, it is
      programmer must make sure that the task whose attribute is being
controlled manner. Each Ada implementation must document many characteristics
implementation must document various properties of the implementation:
manner. Each Ada implementation must document all implementation-defined
certain target machine dependences. Each Ada implementation must document
@ grep -i must rm.txt |wc
     22     224    1637
@ grep -i must aarm.txt |wc
    122    1271    8910
@ 

I'll bet most of these come from Ada 83 or Ada 95 wording.

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

From: Randy Brukardt
Sent: Thursday, February 14, 2008  9:55 PM

> > A document by Derek Jones indicated that the Ada 2005
> > standard had 22 occurrences of "must."  Needless
> > to say that surprised me.  So I did a search.

I see the new presentation AI will get started with a bang (for those of you
who missed the recent meeting, we approved and closed the existing
presentation AI as it was getting too long).

I'm surprised, too, that despite some care we managed to forget that basic
rule that many times.

> > I found the following 14 "musts":
> >
> >    3.3.1(20.4)
> >    3.9.4(26/2), 3.9.4(33/2) (both from an Example)
> >    6.3.1(21.1)
> >    7.5(9/2) (a Note)
> >    12.6(16.1)(a Note)
> >    13.3(8.1/2), 13.13.2(55/2), 13.13.2(56/2)
> >    C.7.2(30/2), C.7.2(32) ("must" is used in non-technical way)
> >    M(1/2), M.1(1/2), M.2(1/2), M.3(1/2)
> >
> > I'm not sure where the other 8 could be hiding.

Umm, Tucker, there are 15 items in this list. That explains at least one
that is "missing".

There are 5 "must"s in the Introduction (paragraphs 11, 13, 19/2, 38, 41/2).
I don't see any reason to change these.

There are two "must"s in the single paragraph 3.3.1(20.4/2). There also are
two "must"s in the note 7.5(9/2).

> > Only 9 of the above 14 are actually clear places
> > where "shall" should have been used instead.
> > The others are informal uses of "must."  We might
> > still want to purge them all, however, just to avoid
> > any confusion about what are the real requirements.
>
> What document by Derek Jones are you talking about?
>
> I object to blindly changing "must" to "shall".  Eschew obfuscation. Certainly
> the ones in "Language Summary" and "Examples" and other informal places can
> remain as is.

I think I agree. It's not worth changing.

> The two in 3.3.1(20.4) can be fixed by changing "must precede" to "precede",
> which matches the style used in the immediately preceding paragraphs, and
> I think matches the general style of "Dynamic Semantics", which says what
> happens, not what "shall happen".
>
> In 6.3.1(21.1), "must be" should be "is"; it's a definition.
>
> In 13.3(8.1/2), I could tolerate changing "must include" to
> "shall include",
> but "includes" would be just as good.
>
> In 13.13.2(55/2), "must" should be "shall".
>
> In 13.13.2(56/2), "must" should probably be "shall".
>
> Annex M is informative, so should not use "shall".

What is the alternative? A quick attempt to use other words doesn't seem to
work. Of course, leaving it as it is would be fine. OTOH, this is really
just reiterating requirements given elsewhere, so I don't think "shall" is
so bad.

> None of this has the slightest effect on implementers or users; as usual
in
> such cases, I'm happy to take "!No Action".
>
> I get 22 occurrences, by the way:
...

This didn't help any, as these are completely without (useful) context.
Other than to verify the number!

The search engine didn't help any, either - every page got matched whether
it contained "must" or not.(I'm not quite sure why, but I'm not curious
enough to go debug the code - one likely possibility is that it is a word
that is omitted from indexing and there is some bug in the override code
that is supposed to deal with the special case of finding unindexed words.)

I ended up doing a text search on the HTML text, which came up with a small
set of pages, and then searching each page individually in Firefox.

> I'll bet most of these come from Ada 83 or Ada 95 wording.

How much? The winnings would help ease my embarrassment about this issue!
Note that virtually every paragraph number in question has a /2 (meaning it
was modified or new Ada 2005 wording).

I'm embarrassed because this is something that I'm always explicitly looking
for, and I'm surprised that I missed that many. (While the rest of you are
also supposed to note such mistakes during editorial review, I get paid to
find them, so I'm not happy when I fail to do so.) I don't recall ever doing
a search for the word, though -- obviously we should have done that.

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

From: Tucker Taft
Sent: Thursday, February 14, 2008  10:14 PM

To answer Bob's question about "what document by
Derek Jones are you talking about," he sent it
to the OWGV mailing list.  OWGV is an ISO working
group focusing on language vulnerabilities.
The document is called "Forms of language
specification."  I could ask him whether I could
forward it to the ARG mailing list if there
is sufficient interest.

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

From: Robert A. Duff
Sent: Friday, February 15, 2008  7:09 PM

> > Annex M is informative, so should not use "shall".
                                      ^^^

> What is the alternative?

I think you missed the "not" -- that is, we agree that Annex M
need not change.

> I ended up doing a text search on the HTML text, which came up with a small
> set of pages, and then searching each page individually in Firefox.

Now you know why I like the .txt version!

After doing the grep, I did an incremental search in Emacs.
It's nice to have fancy fonts and formatting, but for searching
and cut&paste into emails, you can't beat the plain old 7-bit ascii!
(I concatenated all the *.txt files by hand, of course.
In the correct order.)

> > I'll bet most of these come from Ada 83 or Ada 95 wording.
> 
> How much? The winnings would help ease my embarrassment about this issue!

My standard amount in these cases is a nickel.  I didn't search the older
versions, but I thought I recognized some from Ada 83 -- particularly in
the "Language Summary".

I don't see any need for embarrassment.  There are NOT 22 bugs -- just 22 cases
to be looked at, and when I looked at them, I found only one case that
definitely ought to be "shall", and one "probable" case.  One and a half
minor bugs isn't a big deal!  (I looked at about 3/4 of the 22.)

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

!topic S'Safe_[l]{L}ast
!reference Ada 2005 RM G.2.2(11)
!author Grein 2008.04.23

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

Questions? Ask the ACAA Technical Agent