Version 1.11 of ai05s/ai05-0004-1.txt
!standard C.7.1(17/2) 07-09-05 AI05-0004-1/08
!standard 1.1.4(14.1/2)
!standard 3.8(11)
!standard 3.8(13.1/2)
!standard 3.9.4(22/2)
!standard 3.9.4(29/2)
!standard 3.10.2(12.2/2)
!standard 4.1(7)
!standard 4.3.3(32)
!standard 7.3(10.1/2)
!standard 7.4(10)
!standard 7.6(16)
!standard 7.6(18)
!standard 10.1.3(10)
!standard 10.1.1(17)
!standard 12.3(7)
!standard A.11(4/2)
!standard A.18.7(58/2)
!standard A.18.7(79/2)
!standard A.18.7(82/2)
!standard D.9(6)
!standard J.1
!class presentation 06-03-15
!status work item 06-05-12
!status received 06-03-15
!priority Low
!difficulty Easy
!qualifier Omission
!subject Presentation issues in the Standard.
!summary
This AI corrects minor errors in the Standard.
1) C.7.1(17/2) should say entry_body rather than entry body.
2) 3.8(13.1/2) should say record_type_definition rather than record_type_declaration.
3) 3.10.2(12.2/2) should say record_component_association rather than component_association.
4) 4.3.3(32) should say parenthesized expression rather than parenthesized_expression.
5) 4.1(7) should say attribute_references rather than attributes.
6) 7.3(10.1/2) should say "defined by a derived_type_definition"
rather than "is a derived_type_declaration".
7) D.9(6) should say select_alternative rather than selective_accept_alternative.
8) 12.3(7) should say (twice) generic_association rather than generic_parameter_assocation.
9) 10.1.3(10) should say task declaration and protected declaration.
10) A.11(4/2) should say Wide_Wide_Text_IO.Wide_Wide_Bounded_IO.
11) The title of J.1 should be "Renamings of Library Units from Previous Versions
of this Standard".
12) "exponent" in 1.1.4(14.1/2) should be in the sans-serif font.
13) The second sentence of 10.1.1(17) is deleted.
14) "Count" should be "Cur_Count" in 3.9.4(22/2).
15) "Union" should be "Intersection" in A.18.7(58/2).
16) A.18.7(79/2) should appear after A.18.7(82/2).
17) 3.8(11) should include operational items.
18) 7.4(10) should include access_definition.
19) The mode of Person in Remove_First in 3.9.4(29/2) should be "out" not "in".
20) Assignment operations are now defined for limited types, so 7.6(16) and 7.6(18)
should not have parenthetical references to "nonlimited".
!question
1) Does C.7.1(17/2) apply to calls to Current_Task in an entry barrier? (Yes.)
2) 3.8(13.1/2) talks about record_type_declaration. But there is no such thing;
was record_type_definition meant instead? (Yes.)
3) 3.10.2(12.2/2) talks about a component_association. But there is no such thing;
was record_component_association meant instead? (Yes.)
4) 4.3.3(32) talks about a parenthesized_expression. But there is no such thing;
was parenthesized expression meant instead? (Yes.)
5) 4.1(7) uses the syntax font for attributes, but the syntax for attributes is called
a attribute_reference. Change this? (Yes.)
6) 7.3(10.1/2) says "is a derived_type_definition", but there is no such thing.
7) D.9(6) talks about a selective_accept_alternative. But there is no such thing;
was select_alternative meant instead? (Yes.)
8) 12.3(7) talks (twice) about a generic_parameter_association, but the syntax just
a few lines above has no such thing. Is generic_association intended? (Yes.)
9) 10.1.3(10) uses "task_declaration" and "protected_declaration", but these are
not defined syntactically. Should "task declaration" and "protected declaration" be
used instead? (Yes.)
10) A.11(4/2) defines Wide_Wide_Text_IO.Wide_Bounded_IO, while A.11(5/2) defines
Wide_Wide_Text_IO.Wide_Wide_Unbounded_IO. One of these names must be wrong.
11) The title of J.1 says "Renamings of Ada 83 Library Units". This is the only
occurrence of "Ada 83" in the Standard, and given that for ISO, that standard was
Ada 87, this looks bad. This title should be changed.
12) 1.1.4(14.1/2) refers to the "definition of exponent". Does this refer to the
syntax "exponent"? It doesn't appear to, because it is not in the syntax font.
13) The second sentence of 10.1.1(17) says:
The renaming of a child of a generic package shall occur only within the
declarative region of the generic package.
10.1.1(18) says:
A child of a parent generic package shall be instantiated or renamed only
within the declarative region of the parent generic.
Considering just renames, these two sentences say exactly the same thing, in
two different ways. And they are adjacent paragraphs in the Standard! Is this
the Department of Redundancy Department? (Yes.)
14) 3.9.4(20/2) defines a dispatching operation Cur_Count (among others). However,
the comment in paragraph 22/2 refers (twice) to "Count". Shouldn't this
should be "Cur_Count"? (Yes.)
15) A.18.7(58/2) is defining the meaning of Intersection, so why does the text
refer to Union? (It should say Union.)
16) A.18.7(79/2) seems to be misplaced; it follows the paragraph that describes
procedure Next. On the other hand, the function Contains, declared in A.18.7(82/2),
has no following descriptive paragraph. Should it be moved? (Yes.)
17) 3.8(11) discusses the use of names in aspect clauses (and aspect pragmas) inside
of record definitions, but unnecessarily restricts them to representation items. Is
there any good reason that (implementation-defined) operational items should be
excluded here? (No.)
18) 7.4(10) defines the elaboration of a deferred constant declaration by lists the
kinds of types that can occur there, but it does not list (anonymous) access_definition.
One presumes that it too should be elaborated here.
19) The mode of Person in Remove_First in 3.9.4(29/2) does not match that of the
interface that it is derived from. Is that correct? (No.)
20) The assignment operation is defined by for all types in the Amendment. But 7.6(16)
and 7.6(18) have parenthetical remarks suggesting that they apply only to nonlimited
types. Should that be corrected? (Yes.)
[Other questions here.]
!recommendation
(See summary.)
!wording
1) C.7.1(17/2) should say entry_body rather than entry body.
2) 3.8(13.1/2) should say record_type_definition rather than record_type_declaration.
3) 3.10.2(12.2/2) should say record_component_association rather than component_association.
4) 4.3.3(32) should say parenthesized expression rather than parenthesized_expression.
5) 4.1(7) should say attribute_reference rather than attribute.
6) 7.3(10.1/2) should say defined by a derived_type_definition.
7) D.9(6) should say select_alternative.
8) 12.3(7) should say generic_assocation.
9) 10.1.3(10) should say task declaration and protected declaration.
10) A.11(4/2) should say Wide_Wide_Text_IO.Wide_Wide_Bounded_IO.
11) The title of J.1 should be "Renamings of Library Units".
12) "exponent" in 1.1.4(14.1/2) should be in the sans-serif font.
13) The second sentence of 10.1.1(17) should be deleted.
14) "Count" (two places) in 3.9.4(22/2) should be "Cur_Count".
15) "Union" in A.18.7(58/2) should be "Intersection".
16) Move A.18.7(79/2) after A.18.7(82/2).
17) 3.8(11) should say "{operational or }representation item".
18) 7.4(10) should say "subtype_indication{, access_definition,} or".
19) 3.9.4(29/2) should be changed as follows:
"procedure Remove_First (Q : in out Fast_Food_Queue; Person : {out}[in] Person_Name);"
2)) The first sentence of 7.6(16) should be modified:
To adjust the value of a [(nonlimited)] composite object, the values of the components
of the object are first adjusted in an arbitrary order, and then, if the object is
{nonlimited} controlled, Adjust is called.
"nonlimited" should be deleted from 7.6(18).
!discussion
1) entry_barrier is syntactically within entry_body. C.7.1(17/2) however, says
"entry body", which is not defined by the Standard. The most reasomable assumption
is that "entry_body" was meant, especially as the intent is that barriers may be
evaluated by any task. We therefore avoid confusion by changing the wording to use
the syntax term.
2) An obvious typo. [Editor's note: This correction was made in the Ada Europe RM edition;
see below for why.]
3) Record_component_association is the only thing that could have been meant; arrays
don't have discriminants anyway. [Editor's note: This correction was made in the Ada
Europe RM edition; see below for why.]
4) There isn't a definition of the term "parenthisized expression", either, even though
we use it all over the place. [Editor's note: This correction was made in the Ada
Europe RM edition; see below for why.]
5) This is talking about the syntax, which is defined directly about it. [Editor's note:
This correction was made in the Ada Europe RM edition; see below for why.]
6) Definitions define types, thus the new wording. [Editor's note:
This correction was made in the Ada Europe RM edition; see below for why.]
7) This is probably an old name for the syntax. [Editor's note:
This correction was made in the Ada Europe RM edition; see below for why.]
8) Oops. [Editor's note: This correction was made in the Ada Europe RM
edition; see below for why.]
9) This is probably an oversight. [Editor's note: This correction was made in the Ada Europe RM
edition; see below for why.]
10) This is an obvious error; Wide_Wide_Text_IO.Wide_Wide_Bounded_IO was obviously
intended.
11) "Ada 83" is meaningless from a standards perspective; it should not be used in
normative text. Besides, this title ("Renamings of Ada 83 Library Units") is wrong:
we're not renaming Ada 83 library units,
we're renaming Ada 95 units so that they can be used like Ada 83 library units.
We could have used "Renamings of Library Units for compatibility with a Previous Version
of this Standard", but that is excessively long and wordy. We could say something like this
in a sentence before J.1(1), but it doesn't seem that important to say here (it is
explained in AARM A(4.b)), as that standard is now quite old.
12) "exponent" refers to the syntax defined in 2.4.1, and should be in the syntax font.
Many of these corrections were made in the Ada Europe edition
of the consolidated reference manual. The original versions were producing linking
errors in the HTML versions (which link syntax terms to their definitions).
But the error is present in the 'official' documents: the final version of the Ada 95 RM,
Corrigendum, and Amendment; so we need to fix these 'officially'.
13) It would not help to have two very similar rules that are written differently.
10.1.1(18) is the more general rule, so we remove the less general second sentence of
10.1.1(17).
14) This was obviously an editing error.
15) This is an obvious cut-and-paste error.
16) This is an objvious placement error. Note that this error is only in the RM, and
not in the Amendment.
17) This appears to be a change missed during the corrigendum work. It would be
weirdly inconsistent not to allow operation items here. Note that there aren't
any language-defined operation items that could be used here, so this change really
only applies to implementation-defined items (as well as future ones).
18) This appears to be a change missed by the Amendment work. Obviously, all kinds of
types should be elaborated; it would be weird to omit one (even if it doesn't do anything
interesting).
19) The mode needs to match that of the primitive subprogram of the interface that we're
deriving from.
20) These two paragraphs apply to all types, and surely should not claim to not apply
to nonlimited types only. The implementation permission of 7.6(17.1/2) depends on 7.6(21/2),
a rule which is under the header of 7.6(18): we better include limited types in 7.6(18).
In addition, 7.6(16) should say that Adjust is called only for nonlimited controlled types,
so that the canonical semantics (before the build-in-place requirement of 7.6(17.1/2)
is applied) is well-defined.
!corrigendum 1.1.4(14.1/2)
Replace the paragraph:
The delimiters, compound delimiters, reserved words, and numeric_literals
are exclusively made of the characters whose code position is between
16#20# and 16#7E#, inclusively. The special characters for which names
are defined in this International Standard (see 2.1) belong to the same
range. For example, the character E in the definition of exponent is the
character whose name is "LATIN CAPITAL LETTER E", not "GREEK CAPITAL
LETTER EPSILON".
by:
The delimiters, compound delimiters, reserved words, and numeric_literals
are exclusively made of the characters whose code position is between
16#20# and 16#7E#, inclusively. The special characters for which names
are defined in this International Standard (see 2.1) belong to the same
range. For example, the character E in the definition of exponent is the
character whose name is "LATIN CAPITAL LETTER E", not "GREEK CAPITAL
LETTER EPSILON".
!corrigendum 3.8(11)
Replace the paragraph:
- A name that denotes any component, protected subprogram, or entry
is allowed within a representation item that occurs within the declaration of
the composite type.
by:
- A name that denotes any component, protected subprogram, or entry
is allowed within an operational or representation item that occurs within the
declaration of the composite type.
!corrigendum 3.8(13.1/2)
Replace the paragraph:
If a record_type_declaration includes the reserved word limited, the
type is called an explicitly limited record type.
by:
If a record_type_definition includes the reserved word limited, the
type is called an explicitly limited record type.
!corrigendum 3.9.4(22/2)
Replace the paragraph:
Queue_Error : exception;
-- Append raises Queue_Error if Count(Q) = Max_Count(Q)
-- Remove_First raises Queue_Error if Count(Q) = 0
by:
Queue_Error : exception;
-- Append raises Queue_Error if Cur_Count(Q) = Max_Count(Q)
-- Remove_First raises Queue_Error if Cur_Count(Q) = 0
!corrigendum 3.9.4(29/2)
Replace the paragraph:
type Fast_Food_Queue is new Queue with record ...;
procedure Append(Q : in out Fast_Food_Queue; Person : in Person_Name);
procedure Remove_First(Q : in out Fast_Food_Queue; Person : in Person_Name);
function Cur_Count(Q : in Fast_Food_Queue) return Natural;
function Max_Count(Q : in Fast_Food_Queue) return Natural;
by:
type Fast_Food_Queue is new Queue with record ...;
procedure Append(Q : in out Fast_Food_Queue; Person : in Person_Name);
procedure Remove_First(Q : in out Fast_Food_Queue; Person : out Person_Name);
function Cur_Count(Q : in Fast_Food_Queue) return Natural;
function Max_Count(Q : in Fast_Food_Queue) return Natural;
!corrigendum 3.10.2(12.2/2)
Replace the paragraph:
- If the value of the access discriminant is determined by a
component_association in an aggregate, the accessibility
level of the object or subprogram designated by the associated
value (or library level if the value is null);
by:
- If the value of the access discriminant is determined by a
record_component_association in an aggregate, the accessibility
level of the object or subprogram designated by the associated
value (or library level if the value is null);
!corrigendum 4.1(7)
Replace the paragraph:
Certain forms of name (indexed_components, selected_components,
slices, and attributes) include a prefix that is either itself
a name that denotes some related entity, or an implicit_dereference
of an access value that designates some related entity.
by:
Certain forms of name (indexed_components, selected_components,
slices, and attribute_references) include a prefix that is either
itself a name that denotes some related entity, or an implicit_dereference
of an access value that designates some related entity.
!corrigendum 4.3.3(32)
Replace the paragraph:
10 In an array_aggregate, positional notation may only be used with two
or more expressions; a single expression in parentheses is interpreted as a
parenthesized_expression. A named_array_aggregate, such as (1 = X),
may be used to specify an array with a single component.>
by:
10 In an array_aggregate, positional notation may only be used with two
or more expressions; a single expression in parentheses is interpreted as a
parenthesized expression. A named_array_aggregate, such as (1 = X),
may be used to specify an array with a single component.>
!corrigendum 7.3.1(10.1/2)
Replace the paragraph:
If the full_type_declaration for a private extension is a
derived_type_declaration, then the reserved word limited shall appear
in the full_type_declaration if and only if it also appears in the
private_extension_declaration.
by:
If the full_type_declaration for a private extension is defined by a
derived_type_definition, then the reserved word limited shall appear
in the full_type_declaration if and only if it also appears in the
private_extension_declaration.
!corrigendum 7.4(10)
Replace the paragraph:
The elaboration of a deferred constant declaration elaborates the subtype_indication
or (only allowed in the case of an imported constant) the array_type_definition.
by:
The elaboration of a deferred constant declaration elaborates the subtype_indication,
access_definition, or (only allowed in the case of an imported constant)
the array_type_definition.
!corrigendum 7.6(16)
Replace the paragraph:
To adjust the value of a (nonlimited) composite object, the values of the components
of the object are first adjusted in an arbitrary order, and then, if the object
is controlled, Adjust is called. Adjusting the value of an elementary
object has no effect, nor does adjusting the value of a composite object with no
controlled parts.
by:
To adjust the value of a composite object, the values of the components
of the object are first adjusted in an arbitrary order, and then, if the object
is nonlimited controlled, Adjust is called. Adjusting the value of an elementary
object has no effect, nor does adjusting the value of a composite object with no
controlled parts.
!corrigendum 7.6(18)
Replace the paragraph:
An implementation is allowed to relax the above rules (for nonlimited controlled
types) in the following ways:
by:
An implementation is allowed to relax the above rules (for controlled types) in
the following ways:
!corrigendum 10.1.1(17)
Replace the paragraph:
A child of a generic library package shall either be itself a generic unit or
be a renaming of some other child of the same generic unit. The renaming of a
child of a generic package shall occur only within the declarative region of
the generic package.
by:
A child of a generic library package shall either be itself a generic unit or
be a renaming of some other child of the same generic unit.
!corrigendum 10.1.3(10)
Replace the paragraph:
A package_body_stub shall be the completion of a package_declaration
or generic_package_declaration; a task_body_stub shall be the
completion of a task_declaration; a protected_body_stub shall
be the completion of a protected_declaration.
by:
A package_body_stub shall be the completion of a package_declaration
or generic_package_declaration; a task_body_stub shall be the
completion of a task declaration; a protected_body_stub shall
be the completion of a protected declaration.
!corrigendum 12.3(7)
Replace the paragraph:
The generic actual parameter is either the explicit_generic_actual_parameter
given in a generic_parameter_association for each formal, or the
corresponding default_expression or default_name if no
generic_parameter_association is given for the formal. When the meaning
is clear from context, the term “generic actual,” or simply “actual,” is used
as a synonym for “generic actual parameter” and also for the view denoted by one,
or the value of one.
by:
The generic actual parameter is either the explicit_generic_actual_parameter
given in a generic_association for each formal, or the
corresponding default_expression or default_name if no
generic_association is given for the formal. When the meaning
is clear from context, the term “generic actual,” or simply “actual,” is used
as a synonym for “generic actual parameter” and also for the view denoted by one,
or the value of one.
!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 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.
!corrigendum A.18.7(58/2)
Replace the paragraph:
Union deletes from Target the elements of Target that are not
equivalent some element of Source.
by:
Intersection deletes from Target the elements of Target that are not
equivalent some element of Source.
!corrigendum A.18.7(79/2)
Delete the paragraph:
Equivalent to Find (Container, Item) /= No_Element.
!corrigendum A.18.7(82/2)
Insert after the paragraph:
function Contains (Container : Set;
Item : Element_Type) return Boolean;
the new paragraph:
Equivalent to Find (Container, Item) /= No_Element.
!corrigendum C.7.1(17/2)
Replace the paragraph:
It is a bounded error to call the Current_Task function from an entry body, or an
interrupt handler, or finalization of a task attribute. Program_Error is raised,
or an implementation-defined value of the type Task_Id is returned.
by:
It is a bounded error to call the Current_Task function from an @fa{entry_body}, or an
interrupt handler, or finalization of a task attribute. Program_Error is raised,
or an implementation-defined value of the type Task_Id is returned.
!corrigendum D.9(6)
Replace the paragraph:
When a delay_statement appears in a delay_alternative of a timed_entry_call
the selection of the entry call is attempted, regardless of the specified
expiration time. When a delay_statement appears in a selective_accept_alternative,
and a call is queued on one of the open entries, the selection of that
entry call proceeds, regardless of the value of the delay expression.
by:
When a delay_statement appears in a delay_alternative of a timed_entry_call
the selection of the entry call is attempted, regardless of the specified
expiration time. When a delay_statement appears in a select_alternative,
and a call is queued on one of the open entries, the selection of that
entry call proceeds, regardless of the value of the delay expression.
!corrigendum J.1(00)
Replace the paragraph:
Renamings of Ada 83 Library Units
by:
Renamings of Library Units
!ACATS test
None needed.
!appendix
From: Tucker Taft
Sent: Wednesday, April 12, 2006 12:48 PM
We have a relative newcomer to Ada doing some of
our Ada 2005 work, and it is useful because it forces
me to actually *read* what we have written in the
reference manual. I came upon this wording in 4.6(24.*):
If there is no type that is the ancestor of both
the target type and the operand type, and they are
not both class-wide types, one of the following
rules shall apply:
* If the target type is a numeric type, ...
* If the target type is an array type, ...
* If the target type is universal access, ...
* If the target type is a general access...
* If the target type is a pool-specific access...
* If the target type is an access-to-subprogram...
In explaining this to our engineer, I found the introductory
paragraph to be a confusing way of putting things. In our
next revision, I would suggest we reword the introductory
paragraph roughly as follows:
If there is no type that is the ancestor of both
the target type and the operand type, and they are
not both class-wide types, then the target type
shall be a numeric type, an array type, or
an access type; further: ... [same bullets as before]
As introduced now, you have to read all of the following bullets
to figure out what kind of types *might* be covered by these
set of rules, and we are relying on the phrase
"one of the following shall apply" to effectively say that
record types do not allow conversions other than those
allowed for in 4.6(21-23.1). And there are a lot of rules to
read (not just the six abstracted above), since most of the rules
have several sub-bullets. For example, are all access types
(including anonymous ones) covered by at least one of the rules?
It takes some time to decide. In general, as written the
introductory paragraph seems to put an undue and unnecessary
burden on the reader to decide whether exactly one of the rules
applies to any given situation.
For what it is worth, the specific case we wanted to know
about was conversion between an interface and a non-interface
type. You can easily get lost in the long-winded rules
relating to access types and think that your case might
be covered.
****************************************************************
From: Pascal Obry
Sent: Monday, May 8, 2006 12:48 PM
The ARM C.7.1, par. 17 says :
<<
It is a bounded error to call the Current_Task function from an entry
body, interrupt handler, or finalization of a task attribute.
Program_Error is raised, or an implementation-defined value of the
type Task_Id is returned.
>>
What about calling Current_Task from an entry barrier ? Is that a
bounded error too ? In this case it should be clearly documented.
****************************************************************
From: Robert A. Duff
Sent: Monday, May 8, 2006 6:40 PM
I don't know what the right answer is.
Why are any of these cases bounded errors? I mean, why not require it to
return some implementation-defined task, in cases where we don't specify which
task executes a particular piece of code? It might even be useful to find out
which task that is -- for example, in the interrupt handler case, mightn't it
be useful to find out which task was interrupted (impl def, of course)?
****************************************************************
From: Randy Brukardt
Sent: Monday, May 8, 2006 7:01 PM
Because that's what Ada 95 chose to do in this case, and there never has
been a compelling reason to change that decision. My understanding is that
these operations not only might be executed by some other task, but they
might be executed by something that is not a task at all (in the sense of
having a TCB, etc.). In that case, raising Program_Error seems like the only
sensible thing to do.
In any case, we shouldn't be changing things like this unless we have to
(why break people's runtimes for trivalities?). It doesn't make sense to
call Current_Task in an entry body anyway; the attribute 'Caller is provided
for this purpose.
****************************************************************
From: Randy Brukardt
Sent: Monday, May 8, 2006 7:08 PM
> What about calling Current_Task from an entry barrier ? Is that a
> bounded error too ? In this case it should be clearly documented.
An entry barrier is syntactally part of an entry body, so I would say that
the rule already covers it by the wording you give. The only question in my
mind is whether "entry body" was supposed to be "entry_body" (there is no
"entry body" defined in Ada [at least, there isn't a definition in the
index]) -- but that seems like hair-splitting. I suppose an AARM note
pointing that "entry body" includes entry barriers wouldn't be a bad idea.
****************************************************************
From: Adam Beneschan
Sent: Monday, May 8, 2006 7:12 PM
> What about calling Current_Task from an entry barrier ? Is that a
> bounded error too ? In this case it should be clearly documented.
Looking at 9.5.2(5), it appears that an entry barrier is syntactically
part of an entry body (or, at least, an entry_body; I think they're
the same thing), so perhaps we should assume that C.7.1(17) would
apply to an entry barrier also, since a call to Current_Task from an
entry barrier *is* a call from an entry body since the entry barrier
is part of the entry body. Anyway, that seems to be the most sensible
interpretation, especially since it leads to the correct result :)
****************************************************************
From: Randy Brukardt
Sent: Monday, May 8, 2006 7:28 PM
I think there is an echo in here. :-) Needless to say, I agree with Adam.
****************************************************************
From: Tucker Taft
Sent: Monday, May 8, 2006 7:38 PM
> Why are any of these cases bounded errors? I mean, why not require it to
> return some implementation-defined task, in cases where we don't specify which
> task executes a particular piece of code? It might even be useful to find out
> which task that is -- for example, in the interrupt handler case, mightn't it
> be useful to find out which task was interrupted (impl def, of course)?
We have generally made things bounded errors when there is
no obvious right and/or meaningful answer, but we don't
want it to be erroneous. The other reason to make it a
bounded error is the hope that it reduces the chance that
implementations are forced to do something expensive but
useless.
****************************************************************
From: Randy Brukardt
Sent: Wednesday, December 20, 2006 7:07 PM
The second sentence of 10.1.1(17) says:
The renaming of a child of a generic package shall occur only within the
declarative region of the generic package.
10.1.1(18) says:
A child of a parent generic package shall be instantiated or renamed only
within the declarative region of the parent generic.
Considering just renames, these two sentences seem to say exactly the same
thing.
It's pretty silly to have two rules that say exactly the same thing.
Especially when they are in adjacent paragraphs. (The only saving grace is
that they're on different pages in the printed version of the consolidated
Ada 95 RM.)
For what it's worth, these rules were added very late in the Ada 9X
process - version 4.0 doesn't have them at all, version 5.0 has them with a
different more complicated version of 10.1.1(18) that only covers instances
(and thus isn't redundant).
Anyway, presuming that I haven't missed some subtlety, what is the best fix
here? (Removing redundant text is a presentation fix, so it is appropriate
to consider it now, and we have a presentation AI.)
(1) Remove the "or renaming" from 10.1.1(18).
(2) Remove the second sentence of 10.1.1(17) completely.
(1) is a smaller change, (2) probably is more understandable (it's weird to
write very similar rules in very different ways).
What do you think?
****************************************************************
From: Tucker Taft
Sent: Wednesday, December 20, 2006 9:16 PM
(2) I would eliminate the separate sentence about renaming completely.
****************************************************************
From: Jean-Pierre Rosen
Sent: Thursday, December 21, 2006 1:29 AM
Vote for (2).
****************************************************************
!topic [Count]{Cur_Count}
!reference Ada 2005 RM 3.9.4(22/2)
!from Niklas Holsti 07-01-24
!discussion
The example starting in paragraph 20/2 defines a limited interface type
Queue with a dispatching operation Cur_Count (among others). However,
the comment in paragraph 22/2 refers (twice) to "Count". I think this
should be "Cur_Count".
****************************************************************
!topic [Union]{Intersection}
!reference Ada 2005 RMA.18.7(58/2)
!from Niklas Holsti
!discussion
The referenced RM paragraph follows the declaration of procedure
Intersection, so it is evidently an editing mistake that the paragraph
starts with the word "Union". This should be "Intersection". The Union
procedure was described in paragraph 54/2.
****************************************************************
!topic Misplaced description of function Contains
!reference Ada 2005 RMA.18.7(79/2)
!from Niklas Holsti 07-01-24
!discussion
The referenced paragraph 79/2 seems to be misplaced; it follows the
paragraph that describes procedure Next. On the other hand, the function
Contains, declared in paragraph 82/2, has no following descriptive
paragraph. Paragraph 79/2 seems to describe function Contains so it
should be moved to lie between paragraphs 82/2 and 83/2.
****************************************************************
!topic mode error in code example
!reference Ada 2005 RM3.9.4(29/2)
!from Author Pascal Pignard 07-07-28
!discussion
In the following section of Ada Reference Manual, ISO/IEC 8652:2007(E) Ed. 3:
3.9.4 Interface Types
...
28/2
Example use of the interface:
29/2
type Fast_Food_Queue is new Queue with record ...;
procedure Append(Q : in out Fast_Food_Queue; Person : in Person_Name); -- error : mode of "Person" does not match
procedure Remove_First(Q : in out Fast_Food_Queue; Person : in Person_Name);
Should be:
procedure Append(Q : in out Fast_Food_Queue; Person : [in]{out} Person_Name);
Because of previous declaration:
23/2
type Synchronized_Queue is synchronized interface and Queue; -- see 9.11
procedure Append_Wait(Q : in out Synchronized_Queue;
Person : in Person_Name) is abstract;
procedure Remove_First_Wait(Q : in out Synchronized_Queue;
Person : out Person_Name) is abstract;
****************************************************************
From: Christoph Grein
Sent: Wednesday, August 1, 2007 1:26 AM
Correction: Remove_First is wrong, not Append
****************************************************************
From: Randy Brukardt
Sent: Friday, August 24, 2007 10:38 PM
Not wanting to do anything tough, I'm working on test objectives for 7.6 this evening
before leaving. I noticed a very minor glitch in 7.6(16) and 7.6(18).
7.6(13-15) talks about the canonical implementation of the assignment operation. That
is now defined for limited types. 7.6(16) defines adjustment for, including a call to
Adjust. The paragraph parenthetically claims to apply only to non-limited types, but that
begs the question of what the meaning of this is for limited types. (Yes, I know that
later requirements are intended to make this moot, but should the canonical semantics
really be undefined??)
So I suggest removing the parenthetical non-limited, and adding a word to make it clear
that adjusting a limited type is a no-op (and surely does not call a routine that does
not exist!):
"To adjust the value of a [(nonlimited)] composite object, the values of the components
of the object are first adjusted in an arbitrary order, and then, if the object is
{nonlimited} controlled, Adjust is called. Adjusting the value of an elementary object
has no effect, nor does adjusting the value of a composite object with no controlled parts."
We could add something to the last phrase about limited objects, but since it is already
considered redundant, it isn't necessary (and might be considered conflicting with the
requirements following).
The AARM note at 7.6(16.a) also needs a bit of repair.
There is a similar problem with 7.6(18). It has a parenthetical "for nonlimited
controlled types", but 7.6(21/2) is the rule that 7.6(17.1/2) is requiring to be
implemented -- for both limited and nonlimited aggregates (and functions for that
matter). It's quite clear that 7.6(21/2) *can* happen for limited types, the
so-called proof of 7.6(18.a) notwithstanding.
So I propose dropping "nonlimited" from 7.6(18) and fixing 7.6(18.a) to read
something like:
Ramification: The rules below about assignment_statements apply only to
nonlimited controlled types, as assignment_statements are not allowed for
limited types. The other rule applies to both limited and nonlimited types,
and in fact is required for all assignment operations involving aggregates
and function calls. This is important because the programmer can count on
a stricter semantics for limited controlled types.
As both of these are parenthetical remarks, they don't affect the correctness of
the language. As such, I propose to add these changes to the presentation AI.
****************************************************************
Questions? Ask the ACAA Technical Agent