Version 1.17 of ai05s/ai05-0004-1.txt
!standard C.7.1(17/2) 08-05-15 AI05-0004-1/12
!standard 1.1.2(21)
!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.1.4(3)
!standard 4.3.3(32)
!standard 7.3(10.1/2)
!standard 7.4(10)
!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 Amendment 201Z 08-11-26
!status WG9 Approved 08-06-20
!status ARG Approved 9-0-0 08-02-08
!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) The title of Annex M has changed, so the reference to it in 1.1.2(21) should be to
"Summary of Documentation Requirements".
21) Mod should be included in the list of attribute designators in 4.1.4(3).
!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
an 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 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 Intersection.)
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 listing 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) 1.1.2(21) refers to Annex M as "Implementation-Defined Characteristics", but the
Amendment changed the name to "Summary of Documentation Requirements". Should this be
corrected? (Yes.)
21) 4.1.4(3) gives a list of attribute designators, explicitly allowing those attribute
names which are reserved words. The Amendment added the Mod attribute, whose name is
a reserved word, but it was not added to this syntax. Should this be done? (Yes.)
!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_association.
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".
Add an AARM ramification:
For non-imported constants, these elaborations cannot require any code or checks
for a legal program, because the given subtype_indication has to be indefinite
or statically match that of the full constant, meaning that either it is a
subtype_mark or it has static constraints. If the deferred constant instead has
an access_definition, the designated subtype must be a subtype_mark.
We still say that these are elaborated, however, because part of elaboration
is creating the type, which is clearly needed for access_definitions.
(A deferred constant and its full constant have different types when
they are specified by an access_definition, although there is no
visible effect of these types being different as neither can be named.)
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);"
20) 1.1.2(21) should say Annex M, "Summary of Documentation Requirements".
21) 4.1.4(3) should include "Mod".
!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 reasonable 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 "parenthesized 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.]
The marked corrections were made in the Ada Europe (printed) 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'.
10) This is an obvious error; Wide_Wide_Text_IO.Wide_Wide_Bounded_IO was obviously
intended. [Editor's note: This correction was made in the Ada Europe RM
edition to avoid confusion. As noted above, it needs to be made 'officially'.]
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.
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 obvious 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 operational items here. Note that there aren't
any language-defined operational 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) The Ada Europe version (both on-line and printed), incorrectly references clause M.2 in
this paragraph, because the old Annex title was used for that clause (and the tools thus
used it for the cross-reference). Obviously, we want to use the correct title.
21) This is a clear oversight. Surely it is intended to be able to write the 'Mod attribute,
which the standard carefully defines.
!corrigendum 1.1.2(12)
Replace the paragraph:
Annex M, "Implementation-Defined Characteristics"
by:
Annex M, "Summary of Documentation Requirements"
!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.1.4(3)
Replace the paragraph:
attribute_designator ::=
identifier[(static_expression)]
| Access | Delta | Digits | Mod
by:
attribute_designator ::=
identifier[(static_expression)]
| Access | Delta | Digits
!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 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
****************************************************************
!topic attribute_designator misses Mod keyword
!reference Ada 2005 RM 4.1.4(3)
!from Maxim Reznik 07-12-26
!keywords mod attribute designator
!discussion
New attribute Mod was introduced in RM-3.5.4(16.1/2).
Mod is reserved keyword according to RM-2.9 (2.b), so
attribute_designator syntax rule should include it:
attribute_designator ::=
identifier[(static_expression)]
| Access | Delta | Digits | Mod
****************************************************************
Questions? Ask the ACAA Technical Agent