Version 1.5 of ai05s/ai05-0004-1.txt
!standard C.7.1(17/2) 07-01-12 AI05-0004-1/03
!standard 1.1.4(14.1/2)
!standard 3.8(13.1/2)
!standard 3.10.2(12.2/2)
!standard 4.1(7)
!standard 4.3.3(32)
!standard 7.3(10.1/2)
!standard 9.1(9.4/2)
!standard 10.1.3(10)
!standard 10.1.1(17)
!standard 12.3(7)
!standard A.11(4/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.
!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.)
[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 from Previous Versions
of this Standard".
12) "exponent" should be in the sans-serif font.
13) The second sentence of 10.1.1(17) should be deleted.
!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.
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).
!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(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.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 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 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 from Previous Versions
of this Standard
!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).
****************************************************************
Questions? Ask the ACAA Technical Agent