!standard  3.3.1(20.4/2)                             11-02-01  AI05-0092-1/15
!standard  3.3.1(23)
!standard  3.9(25.1/2)
!standard  6.3.1(21.1/2)
!standard  7.6(9.3/2)
!standard  9.6(6)
!standard  9.6(8)
!standard  9.6(22)
!standard 13.3(75/1)
!standard 13.13.2(55/2)
!standard 13.13.2(56/2)
!standard A.11(4/2)
!standard A.11(5/2)
!standard A.16(44/2)
!standard A.16(68/2)
!standard A.16(104/2)
!standard A.16(112/2)
!standard A.18.2(189/2)
!standard A.18.10(2/2)
!standard A.18.11(2/2)
!standard A.18.12(2/2)
!standard A.18.13(2/2)
!standard A.18.14(2/2)
!standard A.18.15(2/2)
!standard D.5.1(18)
!standard D.14.2(4/2)
!standard D.14.2(21/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) Replace "must include" with "includes" in 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).

6) Drop the "3.9.2" reference from 13.3(75/1).

7) In A.11(4-5/2), replace "Wide_Bounded_String" with "Bounded_Wide_String" and
"Wide_Wide_Bounded_String" with "Bounded_Wide_Wide_String".

8) Replace "Interface_Ancestor_Tag" with "Interface_Ancestor_Tags" in 3.9(25.1/2).

9) The routines Wide_Expanded_Name and Wide_Wide_Expanded_Name should be listed
in 3.9(25.1/2).

10) Replace "_statement" with "statement".

11) Add a default of "" to the Form parameter.

12) The existing indefinite container forms have differences in contents and in
semantics.

13) Correct the note D.5.1(18).

14) Correct the note 3.3.1(23).

15) Correct A.16(104/2) and A.16(112/2).

16) Change "List" to "Vector" in A.18.2(189/2).

17) Replace "that with "whose type" in 7.6(9.3/2)

18) Replace "P" in D.14.2(4/3) and D.14.2(21/3).

19) Ada.Real_Time.Time is a time-type.

20) The private part should match other language-defined packages.

!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.)

6) 13.3(75/1) says "See 3.9.2 and 13.13.2". There doesn't appear to be anything
relevant in 3.9.2. What is the intent? (Delete it.)

7) A.11(4-5/2) use the wrong names for the Wide and Wide_Wide versions of
bounded strings. Fix these? (Yes.)

8) 3.9(25.1/2) mentions "Interface_Ancestor_Tag", but there is no such thing.
Change to "Interface_Ancestor_Tags"? (Yes.)

9) 3.9(25.1/2) mentioned "Expanded_Name", but it doesn't mention "Wide_Expanded_Name"
and "Wide_Wide_Expanded_Name". Should it? (Yes.)

10) 9.6(22) includes "_statement"; this fragment is unseemly. Should this be replaced
by "statement"? (Yes.)

11) A.16(13/2) includes a default of "" for the Form parameter, but A.16(68/2) does
not. Should A.16(68/2) have a default for the Form parameter? (Yes.)

12) A.18.10(2/2) [and the other 5 indefinite container forms] says that the contents
of package Indefinite_Vectors differs from the contents of package Vectors, but the
semantics is changed in various ways as well. Should the wording reflect this? (Yes.)

13) The Note D.5.1(18) talks about when Tasking_Error is raised by Set_Priority. But
Tasking_Error is never raised by Set_Priority, so this note is confusing.

14) The Note 3.3.1(23) says that a formal_object_declaration
"is not called a stand-alone object", while 12.4(10/2) says that a
formal_object_declaration of mode in is "a stand-alone constant object"
within an instance. This note must be wrong, should it be fixed? (Yes.)

15) A.16(104/2) and A.16(112/2) contain the text "If the Pattern is null, ...".
But Pattern is of type String and cannot be null. Should this be fixed? (Yes.)

16) A.18.2(189/2) has a parameter type of "List"; but this is the vector package.
Should this be fixed? (Yes.)

17) 7.6(9.1-9.6/2) define "needs finalization" on types. But 7.6(9.3/2) talks about
components: these are objects not types. This needs to say something about
"a component whose type needs finalization". Should this be fixed? (Yes.)

18) AI05-0167-1 uses "CPU" as the discriminant and parameter name when
representating a processor. AI05-0169-1 uses "P" instead. Should these be the
same? (Yes.)

19) The second sentence of 9.6(6) (a Legality Rule) says, "The type of the
delay_expression in a delay_until_statement shall be a time
type--either the type Time defined in the language-defined package
Calendar (see below), or some other implementation-defined time type
(see D.8)."

Ada.Real_Time.Time is supposed to be one of those possible
time types (and D.8(18) says so explicitly), but since it's defined by
the language, it isn't "implementation-defined", so strictly speaking
this rule doesn't allow it. Should this be fixed? (Yes.)

20) The private part of Ada.Directories says "-- Not specified by the language."
while other packages "... -- not specified by the language" (dots, lower case
'n', no period). This should be consistent.

[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) Replace "must include" by "includes" in 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).

6) Remove "3.9.2 and" from 13.3(75/1).

7) In A.11(4-5/2), replace "Wide_Bounded_String" with "Bounded_Wide_String" and
"Wide_Wide_Bounded_String" with "Bounded_Wide_Wide_String".

8) Replace "Interface_Ancestor_Tag" with "Interface_Ancestor_Tags" in 3.9(25.1/2).

9) Replace "or Parent_Tag" with "Parent_Tag, Wide_Expanded_Name, or
Wide_Wide_Expanded_Name" in 3.9(25.1/2).

10) Replace "_statement" with "statement" in 9.6(22).

11) Replace "Form : in String);" with "Form : in String := "");" in A.16(68/2).

12) Add "and semantics" after "contents" in A.18.10(2/2), A.18.11(2/2), A.18.12(2/2),
A.18.13(2/2), A.18.14(2/2), and A.18.15(2/2).

13) Modify the Note D.5.1(18):

32  The rule for when Tasking_Error is raised for Set_Priority or Get_Priority is
different from the rule for when Tasking_Error is raised on an entry call (see 9.5.3).
In particular, [setting or ]querying the priority of a completed or an abnormal task is
allowed, so long as the task is not yet terminated{, and setting the priority of a task
is allowed for any task state (including for terminated tasks)}.

14) Modify the Note 3.3.1(23):

An object declared by a loop_parameter_specification, parameter_specification,
entry_index_specification, choice_parameter_specification,
{extended_return_statement,} or a formal_object_declaration {of mode IN OUT} is
not [called] {considered} a stand-alone object.

15) Modify A.16(104/2) and A.16(112/2):

... If Pattern is {the} null {string},

16) Replace "List" with "Vector" in A.18.2(189/2).

17) Replace "that" with "whose type" in 7.6(9.3/2).

18) Replace "P" by "CPU" in D.14.2(4/3) and replace
"processor P" by "CPU" in D.14.2(21/3).

19) Modify 9.6(6) as "... package Calendar (see below), 
{the type Time in the package Real_Time (see D.8), } or some other implementation-defined
time type[(see D.8)]."

Delete "implementation-defined" from 9.6(8).

20) Change A.16(44/2) to "... -- not specified by the language".

!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.

6) It's possible the author meant 3.9, but that wouldn't be useful, as 3.9(11)
just references 13.3. We surely don't want a circular definition, so we just
drop the reference.

7) The names of the types ought be consistent between A.4.7, A.4.8, and A.11.

8) An obvious missing 's'.

9) The Wide and Wide_Wide versions of Expanded_Name surely should raise the same
exceptions as the base version. Anything else would be madness. Note that the
routines are listed in alphabetical order.

10) This is one of a number of similar fragments in the Ada 95 RM. As they interfere
with automated linking and indexing (and look like a mistake), we've been eliminating
them when possible. We could have used the entire "delay_statement" here, but that
would seem redundant (there are two other occurrences of delay_statement in the
paragraph).

11) Clearly the specifications given in A.16(13/2) and A.16(68/2) should match.
Since Form parameters generally default to "", we believe that A.16(13/2) is
correct and change A.16(68/2) to match.

12) It is obvious that more than just the contents are changed for the indefinite
forms. For instance, A.18.10(8/2) is not referring to the contents of the package.
It is best if the wording reflects that.

13) The note is technically correct, but it is misleading. The rewrite makes it
clearer that Set_Priority is always allowed.

14) We don't like notes that lie, so we correct it to match the normative
semantics. (We have no reason to assume that the normative semantics are wrong.)
We also mention extended return objects in this list, since they are a similar
kind of object that is not considered stand-alone.

15) "null" clearly should be "null string". We use the form "Pattern is the null
string" because text of that form occurs in multiple places in A.16 already.

16) There is nothing named "List" in this package, so this must be a simple
cut-and-paste error.

17) The questioner is right; we need to say something about the type of the
component.

18) These two AIs should use similar names.

19) Clearly, Real_Time.Time is supposed to be a time type. There is even a
cross-reference in the rule in question - but it isn't implementation-defined.
Since the cross-reference is already there, we might as well go all the way and
identify the type, too, and then we don't need to weasel about what we mean.

OTOH, this will make the language a bit more fragile; if another language-defined
time type is ever created, we'd need to update this paragraph again.

An alternative that we considered was to simply echo 9.5.1(18):

"... package Calendar (see below), or some other type that is identified as a
time type where it is defined (see D.8)."

This isn't as fragile, but no longer includes the indication that
implementation-defined time types are expected. Moreover, the cross-reference
is still mysterious.

We could also just add language defined to the existing rule:

"... package Calendar (see below), or some other language-defined or
implementation-defined time type (see D.8)."

but here the cross-reference seems to associate with "implementation-defined"
which makes no sense. Reversing the two hyphenated terms fixes that, but then
they are in a weird order.

So we chose the wording given above.

Note that we also fix 9.6(8). There is no need to mention where the time type is
defined in this sentence, so we just drop it.

20) Ada.Directories is different from all other language-defined packages, so
make it consistent.

!corrigendum 3.3.1(20.4/2)

@drepl
@xbullet<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.>
@dby
@xbullet<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 3.3.1(23)

@drepl
@xindent<@s9<8 As indicated above, a stand-alone object is an object declared
by an @fa<object_declaration>. Similar definitions apply to "stand-alone
constant" and "stand-alone variable." A subcomponent of an object is not a
stand-alone object, nor is an object that is created by an @fa<allocator>. An
object declared by a @fa<loop_parameter_specification>,
@fa<parameter_specification>, @fa<entry_index_specification>,
@fa<choice_parameter_specification>, or a @fa<formal_object_declaration> is
not called a stand-alone object.>>
@dby
@xindent<@s9<8 As indicated above, a stand-alone object is an object declared
by an @fa<object_declaration>. Similar definitions apply to "stand-alone
constant" and "stand-alone variable." A subcomponent of an object is not a
stand-alone object, nor is an object that is created by an @fa<allocator>. An
object declared by a @fa<loop_parameter_specification>,
@fa<parameter_specification>, @fa<entry_index_specification>,
@fa<choice_parameter_specification>, @fa<extended_return_statement>, or
a @fa<formal_object_declaration> of mode @b<in out> is
not considered a stand-alone object.>>

!corrigendum 3.9(25.1/2)

@drepl
Tag_Error is raised by a call of Descendant_Tag, Expanded_Name, External_Tag,
Interface_Ancestor_Tag, Is_Descendant_At_Same_Level, or Parent_Tag if any tag
passed is No_Tag.
@dby
Tag_Error is raised by a call of Descendant_Tag, Expanded_Name, External_Tag,
Interface_Ancestor_Tags, Is_Descendant_At_Same_Level, Parent_Tag, Wide_Expanded_Name,
or Wide_Wide_Expanded_Name if any tag passed is No_Tag.

!corrigendum 6.3.1(21.1/2)

@drepl
@xbullet<each @fa<attribute_designator> in one must be the same as the
corresponding @fa<attribute_designator> in the other; and>
@dby
@xbullet<each @fa<attribute_designator> in one is the same as the
corresponding @fa<attribute_designator> in the other; and>

!corrigendum 7.6(9.3/2)

@drepl
@xbullet<it has a component that needs finalization; or>
@dby
@xbullet<it has a component whose type needs finalization; or>

!corrigendum 9.6(6)

@drepl
There can be multiple time bases, each with a corresponding clock, and a corresponding @i<time
type>. The type of the @i<delay_>@fa<expression> in a @fa<delay_until_statement> shall be a
time type @emdash either the type Time defined in the language-defined package Calendar
(see below), or some other implementation-defined time type (see D.8).
@dby
There can be multiple time bases, each with a corresponding clock, and a corresponding @i<time
type>. The type of the @i<delay_>@fa<expression> in a @fa<delay_until_statement> shall be a
time type @emdash either the type Time defined in the language-defined package Calendar
(see below), the type Time in the package Real_Time (see D.8), or some other
implementation-defined time type.

!corrigendum 9.6(8)

@drepl
A value of the type Time in package Calendar, or of some other implementation-defined time type,
represents a time as reported by a corresponding clock.
@dby
A value of the type Time in package Calendar, or of some other time type,
represents a time as reported by a corresponding clock.

!corrigendum 9.6(22)

@drepl
If an attempt is made to @i<cancel> the @fa<delay_statement> (as part of an
@fa<asynchronous_select> or abort — see 9.7.4 and 9.8), the @fa<_statement>
is cancelled if the expiration time has not yet passed, thereby completing the
@fa<delay_statement>.
@dby
If an attempt is made to @i<cancel> the @fa<delay_statement> (as part of an
@fa<asynchronous_select> or abort — see 9.7.4 and 9.8), the statement
is cancelled if the expiration time has not yet passed, thereby completing the
@fa<delay_statement>.


!corrigendum 13.3(8.1/2)

@drepl
A @i<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.
@dby
A @i<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 includes at least the storage element and
the word. Machine scalars are used to interpret component_clauses when the
nondefault bit ordering applies.

!corrigendum 13.3(75/1)

@drepl
@xindent<S'External_Tag denotes an external string representation for S'Tag;
it is of the predefined type String. External_Tag may be specified for a
specific tagged type via an @fa<attribute_definition_clause>; the expression
of such a clause shall be static. The default external tag representation
is implementation defined. See 3.9.2 and 13.13.2. The value of External_Tag
is never inherited; the default value is always used unless a new value
is directly specified for a type.>
@dby
@xindent<S'External_Tag denotes an external string representation for S'Tag;
it is of the predefined type String. External_Tag may be specified for a
specific tagged type via an @fa<attribute_definition_clause>; the expression
of such a clause shall be static. The default external tag representation
is implementation defined. See 13.13.2. The value of External_Tag
is never inherited; the default value is always used unless a new value
is directly specified for a type.>

!corrigendum 13.13.2(55/2)

@drepl
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.
@dby
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)

@drepl
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).
@dby
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 A.11(4/2)

@drepl
The specification of package Wide_Text_IO.Wide_Bounded_IO is the same as that
for Text_IO.Bounded_IO, except that any occurrence of Bounded_String is
replaced by Wide_Bounded_String, and any occurrence of package Bounded is
replaced by Wide_Bounded. The specification of package
Wide_Wide_Text_IO.Wide_Bounded_IO is the same as that for
Text_IO.Bounded_IO, except that any occurrence of Bounded_String is
replaced by Wide_Wide_Bounded_String, and any occurrence of package Bounded
is replaced by Wide_Wide_Bounded.
@dby
The specification of package Wide_Text_IO.Wide_Bounded_IO is the same as that
for Text_IO.Bounded_IO, except that any occurrence of Bounded_String is
replaced by Bounded_Wide_String, and any occurrence of package Bounded is
replaced by Wide_Bounded. The specification of package
Wide_Wide_Text_IO.Wide_Wide_Bounded_IO is the same as that for
Text_IO.Bounded_IO, except that any occurrence of Bounded_String is
replaced by Bounded_Wide_Wide_String, and any occurrence of package Bounded
is replaced by Wide_Wide_Bounded.

!corrigendum A.11(5/2)
The specification of package Wide_Text_IO.Wide_Unbounded_IO is the same as that
for Text_IO.Unbounded_IO, except that any occurrence of Unbounded_String is
replaced by Wide_Unbounded_String, and any occurrence of package Unbounded is
replaced by Wide_Unbounded. The specification of package
Wide_Wide_Text_IO.Wide_Wide_Unbounded_IO is the same as that for
Text_IO.Unbounded_IO, except that any occurrence of Unbounded_String is
replaced by Wide_Wide_Unbounded_String, and any occurrence of package Unbounded
is replaced by Wide_Wide_Unbounded.
@dby
The specification of package Wide_Text_IO.Wide_Unbounded_IO is the same as that
for Text_IO.Unbounded_IO, except that any occurrence of Unbounded_String is
replaced by Unbounded_Wide_String, and any occurrence of package Unbounded is
replaced by Wide_Unbounded. The specification of package
Wide_Wide_Text_IO.Wide_Wide_Unbounded_IO is the same as that for
Text_IO.Unbounded_IO, except that any occurrence of Unbounded_String is
replaced by Unbounded_Wide_Wide_String, and any occurrence of package Unbounded
is replaced by Wide_Wide_Unbounded.

!corrigendum A.16(44/2)

@drepl
@xcode<@b<private>
    -- @ft<@i<Not specified by the language.>>
@b<end> Ada.Directories;>>
@dby
@xcode<@b<private>
    ... -- @ft<@i<not specified by the language>>
@b<end> Ada.Directories;>>


!corrigendum A.16(68/2)

@drepl
@xcode<@b<procedure> Copy_File (Source_Name,
                     Target_Name : @b<in> String;
                     Form        : @b<in> String);>
@dby
@xcode<@b<procedure> Copy_File (Source_Name,
                     Target_Name : @b<in> String;
                     Form        : @b<in> String := "");>

!corrigendum A.16(104/2)

@drepl
@xindent<Starts a search in the directory named by Directory for entries
matching Pattern. Pattern represents a pattern for matching file names. If
Pattern is null, all items in the directory are matched; otherwise, the
interpretation of Pattern is implementation-defined. Only items that match
Filter will be returned. After a successful call on Start_Search, the object
Search may have entries available, but it may have no entries available if no
files or directories match Pattern and Filter. The exception Name_Error is
propagated if the string given by Directory does not identify an existing
directory, or if Pattern does not allow the identification of any possible
external file or directory. The exception Use_Error is propagated if the
external environment does not support the searching of the directory with the
given name (in the absence of Name_Error). When Start_Search propagates
Name_Error or Use_Error, the object Search will have no entries available.>
@dby
@xindent<Starts a search in the directory named by Directory for entries
matching Pattern. Pattern represents a pattern for matching file names. If
Pattern is the null string, all items in the directory are matched; otherwise,
the interpretation of Pattern is implementation-defined. Only items that match
Filter will be returned. After a successful call on Start_Search, the object
Search may have entries available, but it may have no entries available if no
files or directories match Pattern and Filter. The exception Name_Error is
propagated if the string given by Directory does not identify an existing
directory, or if Pattern does not allow the identification of any possible
external file or directory. The exception Use_Error is propagated if the
external environment does not support the searching of the directory with the
given name (in the absence of Name_Error). When Start_Search propagates
Name_Error or Use_Error, the object Search will have no entries available.>

!corrigendum A.16(112/2)

@drepl
@xindent<Searches in the directory named by Directory for entries matching
Pattern. The subprogram designated by Process is called with each matching entry
in turn. Pattern represents a pattern for matching file names. If Pattern is
null, all items in the directory are matched; otherwise, the interpretation of
Pattern is implementation-defined. Only items that match Filter will be
returned. The exception Name_Error is propagated if the string given by
Directory does not identify an existing directory, or if Pattern does not allow
the identification of any possible external file or directory. The exception
Use_Error is propagated if the external environment does not support the
searching of the directory with the given name (in the absence of Name_Error).>
@dby
@xindent<Searches in the directory named by Directory for entries matching
Pattern. The subprogram designated by Process is called with each matching entry
in turn. Pattern represents a pattern for matching file names. If Pattern is the
null string, all items in the directory are matched; otherwise, the
interpretation of Pattern is implementation-defined. Only items that match
Filter will be returned. The exception Name_Error is propagated if the string
given by Directory does not identify an existing directory, or if Pattern does
not allow the identification of any possible external file or directory. The
exception Use_Error is propagated if the external environment does not support
the searching of the directory with the given name (in the absence of
Name_Error).>

!corrigendum A.18.2(189/2)

@drepl
@xcode<@b<procedure> Reverse_Elements (Container : @b<in out> List);>
@dby
@xcode<@b<procedure> Reverse_Elements (Container : @b<in out> Vector);>

!comment The containers clauses have been renumbered; following is the new numbers.

!corrigendum A.18.11(2/2)

@drepl
The declaration of the generic library package Containers.Indefinite_Vectors has
the same contents as Containers.Vectors except:
@dby
The declaration of the generic library package Containers.Indefinite_Vectors has
the same contents and semantics as Containers.Vectors except:

!corrigendum A.18.12(2/2)

@drepl
The declaration of the generic library package Containers.Indefinite_Doubly_Linked_Lists
has the same contents as Containers.Doubly_Linked_Lists except:
@dby
The declaration of the generic library package Containers.Indefinite_Doubly_Linked_Lists has
the same contents and semantics as Containers.Doubly_Linked_Lists except:

!corrigendum A.18.13(2/2)

@drepl
The declaration of the generic library package Containers.Indefinite_Hashed_Maps has
the same contents as Containers.Hashed_Maps except:
@dby
The declaration of the generic library package Containers.Indefinite_Hashed_Maps has
the same contents and semantics as Containers.Hashed_Maps except:

!corrigendum A.18.14(2/2)

@drepl
The declaration of the generic library package Containers.Indefinite_Ordered_Maps has
the same contents as Containers.Ordered_Maps except:
@dby
The declaration of the generic library package Containers.Indefinite_Ordered_Maps has
the same contents and semantics as Containers.Ordered_Maps except:

!corrigendum A.18.15(2/2)

@drepl
The declaration of the generic library package Containers.Indefinite_Hashed_Sets has
the same contents as Containers.Hashed_Sets except:
@dby
The declaration of the generic library package Containers.Indefinite_Hashed_Sets has
the same contents and semantics as Containers.Hashed_Sets except:

!corrigendum A.18.16(2/2)

@drepl
The declaration of the generic library package Containers.Indefinite_Ordered_Sets has
the same contents as Containers.Ordered_Sets except:
@dby
The declaration of the generic library package Containers.Indefinite_Ordered_Sets has
the same contents and semantics as Containers.Ordereds except:

!corrigendum D.5.1(18)

@drepl
@xindent<@s9<32  The rule for when Tasking_Error is raised for Set_Priority or Get_Priority is
different from the rule for when Tasking_Error is raised on an entry call (see 9.5.3).
In particular, setting or querying the priority of a completed or an abnormal task is
allowed, so long as the task is not yet terminated.>>
@dby
@xindent<@s9<32  The rule for when Tasking_Error is raised for Set_Priority or Get_Priority is
different from the rule for when Tasking_Error is raised on an entry call (see 9.5.3).
In particular, querying the priority of a completed or an abnormal task is
allowed, so long as the task is not yet terminated, and setting the priority of a task
is allowed for any task state (including for terminated tasks).>>

!corrigendum D.14.2(4/2)

@drepl
@xcode<   @b<type> Group_Budget @b<is tagged limited private>;>
@dby
@xcode<   @b<type> Group_Budget(CPU : System.Multiprocessors.CPU :=
                              System.Multiprocessors.CPU'First)
    @b<is tagged limited private>;>

!corrigendum D.14.2(21/2)

@drepl
The procedure Replenish loads the group budget GB with To as the Time_Span
value. The exception Group_Budget_Error is raised if the Time_Span value To
is non-positive. Any execution of any member of the group of tasks results
in the budget counting down, unless exhausted. When the budget becomes
exhausted (reaches Time_Span_Zero), the associated handler is executed if
the handler of group budget GB is set. Nevertheless, the tasks continue to
execute.
@dby
The procedure Replenish loads the group budget GB with To as the Time_Span
value. The exception Group_Budget_Error is raised if the Time_Span value To
is non-positive. Any execution on CPU of any member of the group of
tasks results in the budget counting down, unless exhausted. When the budget
becomes exhausted (reaches Time_Span_Zero), the associated handler is executed
if the handler of group budget GB is set. Nevertheless, the tasks continue to
execute.

!corrigendum G.2.2(11)

@drepl
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.
@dby
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

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

!topic Strange reference in 13.3(75)
!reference 13.3(75), 3.9.2
!from Adam Beneschan 08-05-19
!discussion

Presentation nitpick:

13.3(75) reads:

    S'External_Tag denotes an external string representation for
    S'Tag; it is of the predefined type String. External_Tag may be
    specified for a specific tagged type via an
    attribute_definition_clause; the expression of such a clause shall
    be static. The default external tag representation is
    implementation defined. See 3.9.2 and 13.13.2. The value of
    External_Tag is never inherited; the default value is always used
    unless a new value is directly specified for a type.

Assuming someone reads this and then decides to follow the cross-references,
it's reasonable to think they might try 3.9.2 first since it's listed first;
but the effect is likely to be, "Huh?  Why did it refer me here?" since 3.9.2
says nothing about external tags or anything related to them---at least, I
don't see any connection. If the intent was that 13.13.2(29-34) is the
section that discusses T'Class'Input and 'Output (which use the external tags),
and those sections involve subprogram dispatching, perhaps it would be better
to remove the 3.9.2 reference from 13.3(75) and put them in 13.13.2(29-34).
Or, alternatively, was this 3.9.2 reference a typo (intended to be 3.9,
which would make sense)?

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

!topic Wrong names in Wide_(Un)Bounded_IO package definitions
!reference A.11(4-5), A.4.7, A.4.8
!from Adam Beneschan 08-06-11
!discussion

A.11(4) says:

    The specification of package Wide_Text_IO.Wide_Bounded_IO is the same
    as that for Text_IO.Bounded_IO, except that any occurrence of
    Bounded_String is replaced by Wide_Bounded_String, and any occurrence
                                  ^^^^^^^^^^^^^^^^^^^
    of package Bounded is replaced by Wide_Bounded. The specification of
    package Wide_Wide_Text_IO.Wide_Wide_Bounded_IO is the same as that for
    Text_IO.Bounded_IO, except that any occurrence of Bounded_String is
    replaced by Wide_Wide_Bounded_String, and any occurrence of package
                ^^^^^^^^^^^^^^^^^^^^^^^^
    Bounded is replaced by Wide_Wide_Bounded.

The names noted are incorrect: they should be Bounded_Wide_String and
Bounded_Wide_Wide_String.

There are similar errors in A.11(5).

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

!topic Wrong name, missing names in 3.9(25.1)
!reference 3.9(25.1)
!from Adam Beneschan 08-06-13
!discussion

3.9(25.1) lists Interface_Ancestor_Tag as one of the routines that raises
Tag_Error if given a No_Tag argument.  But the correct name is
Interface_Ancestor_Tags (with an "s" at the end).

Also, it lists Expanded_Name, but shouldn't it also list Wide_Expanded_Name
and Wide_Wide_Expanded_Name?

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

!topic _statement
!reference 9.6(22)
!from Christoph Grein 2008-08-07
!discussion
Quote: "..., the _statement is cancelled ..."
Is the fragment _statement intentional here? (No, I guess. This is already in RM 95.)

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

From: Randy Brukardt
Sent: Saturday, August  9, 2008  12:58 AM

That is quite common in the RM 95; there were many such fragments around.
I've been trying to get rid of them when we have a reason to change a paragraph
anyway, but it doesn't seem important enough to do in general.
(This sort of thing made a mess for the automatic syntax link generator for the
HTML version of the Standard.)

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

From: Randy Brukardt
Sent: Monday, July 6, 2009  7:42 PM

The minutes of the Tallahassee ARG meeting say (under AI05-0001-1):

Change the introductory paragraph to say "...change the contents {and semantics} of the
package...". That makes it clear that the semantics also are changed. Really should make
that change to all of the indefinite forms as well.

The last sentence was intended to cover all of the *existing* indefinite forms as well
as the new ones.

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

From: Bob Duff
Sent: Wednesday, August 19, 2009  3:34 PM

The NOTE at D.5.1(18) is misleading.  Seems to imply that Set_Priority might raise
Tasking_Error for a terminated task.  But D.5.1(7) says it's ignored.

Found by a customer of AdaCore, by the way.  GNAT seems to incorrectly raise T_E.
Probably a "maintenance error".  I guess some earlier version of the RM required T_E,
but wiser heads prevailed, but forgot to update the NOTE.  And this part of the
GNAT runtimes was probably written according to the earlier spec.

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

From: Christoph Grein
Sent: Thursday, November 12, 2009  6:32 AM

13.3(8.1/3) The set of machine scalars is implementation defined, but include{s} at
least the storage element and the word.

"must" was removed, but then grammar requires singular.

[This is item #3 above. - Editor]

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

From: Randy Brukardt
Sent: Monday, March 15, 2010  4:54 PM

I was trying to answer a question about "stand-alone objects", and noticed that
the Note 3.3.1(23) says that a formal_object_declaration "is not called a
stand-alone object", while 12.4(10/2) says that a formal_object_declaration of
mode in is "a stand-alone constant object" within an instance.

One of these must be wrong! We generally have a rule that Notes shouldn't lie,
so I think it needs to be adjusted somehow. (It's interesting that this has been
true since the original Ada 95 standard, and no one has complained before).

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

From: Tucker Taft
Sent: Monday, March 15, 2010  5:06 PM

Good catch.

The note should probably be reworded without the use of the term "called."
E.g.:

   An object declared by a loop_parameter_specification,
   parameter_specification, entry_index_specification,
   choice_parameter_specification, or a
   formal_object_declaration {of mode IN OUT} is not [called]
   {considered} a stand-alone object.

[This is item #14 above - Editor.]

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

From: Bob Duff
Sent: Monday, March 15, 2010  5:11 PM

...
> One of these must be wrong! We generally have a rule that Notes
> shouldn't lie, so I think it needs to be adjusted somehow. (It's
> interesting that this has been true since the original Ada 95
> standard, and no one has complained before).

Are you sure we want to fix this bug, at the risk of putting in new bugs?

To do it right, we'd need to search for all occurrences of "stand-alone".
There are 90 of them.  I'm not inclined to do that work, unless some compiler
writer is likely to do the wrong thing because of this.

The first one is in RM-3.3:

23.5/3   * it is part of a stand-alone constant (including a generic formal
      object of mode in); or

which agrees with 12.4(10/2).

I invented the term "stand-alone object", but now I'm puzzled by it.
I would have thought it means an object that is not allocated by "new", and not
a component of some other object.  And maybe not a parameter (which is
more-or-less view-like).

That is, something that should be stack-allocated, as a whole.
(Viewing static allocation as an optimization of the "stack frame"
of the env task.  And registers as an optimization of stack-allocated
stuff.)

So I'm puzzled by the fact that a loop parameter is not "stand-alone", for
example.

Anyway, I suspect it's the NOTE that is wrong.

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

From: Randy Brukardt
Sent: Monday, March 15, 2010  5:37 PM

> Are you sure we want to fix this bug, at the risk of putting in new
> bugs?

Well, the bug is in a note, so it hardly could be a "new" bug if we change it. I
surely wouldn't change the normative rules (I doubt very much that they are
wrong) unless we were sure there was a problem.

> To do it right, we'd need to search for all occurrences of "stand-alone".
> There are 90 of them.  I'm not inclined to do that work, unless some
> compiler writer is likely to do the wrong thing because of this.

I already did it; I didn't check them all, but most are in notes of various
kinds. (These appear in 28 subclauses.)

> The first one is in RM-3.3:
>
> 23.5/3   * it is part of a stand-alone constant (including a
> generic formal
>       object of mode in); or
>
> which agrees with 12.4(10/2).

I didn't discover this one, though, and it worries me that there is a *real*
bug. Since a loop parameter or extended return object is not a stand-alone
object, there is definitely room for a hole. But it is because of misuse of the
existing term "stand-alone" in next text.

> I invented the term "stand-alone object", but now I'm puzzled by it.
> I would have thought it means an object that is not allocated by
> "new", and not a component of some other object.  And maybe not a
> parameter (which is more-or-less view-like).
>
> That is, something that should be stack-allocated, as a whole.
> (Viewing static allocation as an optimization of the "stack frame"
> of the env task.  And registers as an optimization of stack-allocated
> stuff.)
>
> So I'm puzzled by the fact that a loop parameter is not "stand-alone",
> for example.

The Ada 95 use of the term "stand-alone" is to specify which objects can have
representation clauses. We don't want to be able to give address or size clauses
for loop parameters or subprogram parameters (or extended return objects, for
that matter). I'm surprised that we would want to allow that for formal
parameters of mode in, but the wording is clearly intentional.

I hope that most of the rules actually depend on the wording as it is, and not
using the term as it appears to be. (I unfortunately did that in the AI-144
wording, which is what prompted Steve's question to me.) I worry a bit that
there are more such cases (although I didn't find any given a quick
examination).

[More research on 3.3(23.1-9) shows that whoever wrote that - I think it was
Steve - did check what "stand-alone" was defined to mean, as there is a separate
rule for extended return statements. Loop parameters can't be composite (yet,
anyway), so it doesn't need to be covered there. So there is no problem.]

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

From: Bob Duff
Sent: Monday, March 15, 2010  6:06 PM

> I didn't discover this one, though, ...

Ahah!  Proof that the plain-ascii-text version is A Good Thing!

>...and it worries me that there is a *real*  bug.

Perhaps, but I think "worries" might be a bit overblown.
I mean, let's not have any nightmares over this.

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

From: Randy Brukardt
Sent: Monday, March 15, 2010  6:19 PM

> > I didn't discover this one, though, ...
>
> Ahah!  Proof that the plain-ascii-text version is A Good Thing!

Sorry, Bob, I made a quick scan through the various hits just looking at the
summaries of where the term appeared. I didn't realize this one was in a
legality rule, so I didn't explicitly check it. I just went back and checked,
and the usage itself is reported on the search page. So it was found just fine,
I just didn't open it (nor about 20 of the other hits, either), just like you
didn't look at the other 89 hits you found.

> >...and it worries me that there is a *real*  bug.
>
> Perhaps, but I think "worries" might be a bit overblown.
> I mean, let's not have any nightmares over this.

At the end of my message, I went back and analyzed this particular wording and
found no problem. My concern is more general -- I've made the mistake of not
realizing that some "obvious" cases aren't covered by the term "stand-alone" --
I just wonder if we made that previously as well. Probably not worth worrying
about, though, Adam will find it for us.

I'll put the note fix that Tucker suggested into the presentation AI.

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

From: Lev V. Babchenko
Sent: Tuesday, March 2, 2010  8:57 PM

descriptions of Start_Search and Search procedures in ARM'05 / A.16 are containing
next clause:
"... If Pattern is null, all items in the directory are matched; ..."
(104/2 and 112/2)
but Pattern declared as String and can not contains Null value.
could you replace "null" in desctiprion to something less ambiguous ("empty string"
for example)?

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

From: Randy Brukardt
Sent: Tuesday, March 2, 2010  9:17 PM

"null" here refers to "null string", of course, a term defined for literals in 2.6(6)
and commonly used throughout the standard (4 uses in A.4.3, for instance, as well as
places like A.8.2(4), four other uses in A.16, and seven other clauses).

There is only one use of "empty string" in the standard (C.7.1(7)), and I would
consider that a bug (it's inconsistent with the rest of the standard).

I suppose it would be better if this text said "null string" rather than "null", but
given that there is no chance of confusion (if it meant the null access value "null"
would have been in boldface), making a change here is about the lowest priority fix I
could imagine.

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

!topic Small error in "needs finalization" definition
!reference 7.6(9.3)
!from Adam Beneschan 10-03-24
!discussion

This is a slight nitpick, but...  the definition of "need[s]
finalization" in 7.6 says "A type is said to need finalization if
... it has a component that needs finalization".  Since a component is
an object, not a type, and the "needs finalization" term is defined
for types but not objects, that should probably read "it has a
component whose type needs finalization".

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

Summary of Private exchange between Brad Moore and Randy Brukardt in June 2010:

Brad:
There are inconsistencies between usage of "type-conformant" and "type conformant"
without the hyphen. These need to be made consistent.

Randy:
AI05-0207 is correcting this by removing the hyphen from the existing (ancient)
Ada standard text. Thus the hyphen appears when the original (incorrect) text is
given. I didn't find any other uses of the hyphen.

Brad:
Luke said he counted 14 occurrences of -conformant in the document  
mode-conformant and type-conformant.

Were you planning to remove the mode-conformant hyphens as well?

Randy:
By document, I presume you mean the Ada Standard and not the AI.

I wasn't, because no one had asked me to. Generally, we decided to fix hyphens only
when we were already working on the text in question (because the Ada 95 standard was
wildly inconsistent in how it used hyphens, and fixing all of them would be a massive
job, probably introducing a number of errors on its own).

But if you want me to add that to the presentation AI, I can do that. I didn't find
14 occurrences in normative text, but there definitely are a bunch. Since the term is
defined as "mode conformant" with no hyphen, it is silly to use it with a hyphen
unless it is used as a adjective (which makes no sense for this term).

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

From: Yannick Moy
Sent: Wednesday, September 15, 2010  4:32 AM

The following part of RM A.18.2 should mention a Vector parameter instead of a List one:

189/2 procedure Reverse_Elements (Container : in out List);
190/2   Reorders the elements of Container in reverse order.

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

!topic Mistake in "delay until" legality rule
!reference 9.6(6)
!from Adam Beneschan 10-12-16
!discussion

This came up from a comp.lang.ada thread and was noticed by "BrianG".
The second sentence of 9.6(6) (a Legality Rule) says, "The type of the
delay_expression in a delay_until_statement shall be a time
type--either the type Time defined in the language-defined package
Calendar (see below), or some other implementation-defined time type
(see D.8)."

Obviously, Ada.Real_Time.Time is supposed to be one of those possible
time types (and D.8(18) says so explicitly), but since it's defined by
the language, it can't really be considered "implementation-defined",
and thus it isn't allowed by a literal reading of 9.6(6).  I recommend
changing the last phrase of 9.6(6) to "or some other language-defined
or implementation-defined time type (see D.8)."

Maybe this can be dumped into AI05-0092.

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