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

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

!standard 3.3.1(20.4/2)          11-02-02 AI05-0092-1/16
!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)
!standard J.8(3)
!class presentation 08-03-05
!status Amendment 2012 11-02-04
!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.
21) Correct the example.
!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.
21) The example in J.8 does not show a semicolon after the mod_clause, while the grammar does. Which is right? (The syntax.)
[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".
21) Add a ';' after the second line of J.8(3).
!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.
21) The example doesn't match the Ada 83 syntax, so it must be fixed.
!corrigendum 3.3.1(20.4/2)
Replace the paragraph:
by:
!corrigendum 3.3.1(23)
Replace the paragraph:
8 As indicated above, a stand-alone object is an object declared by an 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 allocator. An object declared by a loop_parameter_specification, parameter_specification, entry_index_specification, choice_parameter_specification, or a formal_object_declaration is not called a stand-alone object.
by:
8 As indicated above, a stand-alone object is an object declared by an 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 allocator. 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 considered a stand-alone object.
!corrigendum 3.9(25.1/2)
Replace the paragraph:
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.
by:
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)
Replace the paragraph:
by:
!corrigendum 7.6(9.3/2)
Replace the paragraph:
by:
!corrigendum 9.6(6)
Replace the paragraph:
There can be multiple time bases, each with a corresponding clock, and a corresponding time type. 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).
by:
There can be multiple time bases, each with a corresponding clock, and a corresponding time type. 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), the type Time in the package Real_Time (see D.8), or some other implementation-defined time type.
!corrigendum 9.6(8)
Replace the paragraph:
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.
by:
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)
Replace the paragraph:
If an attempt is made to cancel the delay_statement (as part of an 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 delay_statement.
by:
If an attempt is made to cancel the delay_statement (as part of an 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 delay_statement.
!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 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)
Replace the paragraph:
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.
by:
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 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)
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 A.11(4/2)
Replace the paragraph:
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.
by:
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.
by:
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)
Replace the paragraph:
private -- Not specified by the language. end Ada.Directories;
>
by:
private ... -- not specified by the language end Ada.Directories;
>
!corrigendum A.16(68/2)
Replace the paragraph:
procedure Copy_File (Source_Name, Target_Name : in String; Form : in String);
by:
procedure Copy_File (Source_Name, Target_Name : in String; Form : in String := "");
!corrigendum A.16(104/2)
Replace the paragraph:
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.
by:
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)
Replace the paragraph:
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).
by:
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)
Replace the paragraph:
procedure Reverse_Elements (Container : in out List);
by:
procedure Reverse_Elements (Container : in out Vector);
!comment The containers clauses have been renumbered; following is the new numbers.
!corrigendum A.18.11(2/2)
Replace the paragraph:
The declaration of the generic library package Containers.Indefinite_Vectors has the same contents as Containers.Vectors except:
by:
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)
Replace the paragraph:
The declaration of the generic library package Containers.Indefinite_Doubly_Linked_Lists has the same contents as Containers.Doubly_Linked_Lists except:
by:
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)
Replace the paragraph:
The declaration of the generic library package Containers.Indefinite_Hashed_Maps has the same contents as Containers.Hashed_Maps except:
by:
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)
Replace the paragraph:
The declaration of the generic library package Containers.Indefinite_Ordered_Maps has the same contents as Containers.Ordered_Maps except:
by:
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)
Replace the paragraph:
The declaration of the generic library package Containers.Indefinite_Hashed_Sets has the same contents as Containers.Hashed_Sets except:
by:
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)
Replace the paragraph:
The declaration of the generic library package Containers.Indefinite_Ordered_Sets has the same contents as Containers.Ordered_Sets except:
by:
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)
Replace the paragraph:
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.
by:
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)
Replace the paragraph:
type Group_Budget is tagged limited private;
by:
type Group_Budget(CPU : System.Multiprocessors.CPU := System.Multiprocessors.CPU'First) is tagged limited private;
!corrigendum D.14.2(21/2)
Replace the paragraph:
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.
by:
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)
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.
!corrigendum J.8(3)
Replace the paragraph:
for r use record at mod a ... end record;
by:
for r use record at mod a; ... end record;
!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.

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

From: Christoph Grein
Sent: Wednesday, February 2, 2011  6:13 AM

J.8(3) for r use record at mod a{;} ...

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

Questions? Ask the ACAA Technical Agent