Version 1.2 of ai05s/ai05-0092-1.txt
!standard 3.3.1(20.4/2) 08-03-05 AI05-0092-1/01
!standard 6.3.1(21.1/2)
!standard 13.13.2(55/2)
!standard 13.13.2(56/2)
!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).
!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.)
[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).
!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).
!corrigendum 3.3.1(20.4/2)
Replace the paragraph:
- The assignments to any components, including implicit components, not
requiring late initialization must precede the initial value evaluations for
any components requiring late initialization; if two components both require
late initialization, then assignments to parts of the component occurring
earlier in the order of the component declarations must precede the initial
value evaluations of the component occurring later.
by:
- The assignments to any components, including implicit components, not
requiring late initialization precede the initial value evaluations for
any components requiring late initialization; if two components both require
late initialization, then assignments to parts of the component occurring
earlier in the order of the component declarations precede the initial
value evaluations of the component occurring later.
!corrigendum 6.3.1(21.1/2)
Replace the paragraph:
- each attribute_designator in one must be the same as the
corresponding attribute_designator in the other; and
by:
- each attribute_designator in one is the same as the
corresponding attribute_designator in the other; and
!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).
!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.)
****************************************************************
Questions? Ask the ACAA Technical Agent