!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) @drepl The delimiters, compound delimiters, reserved words, and @fas 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". @dby The delimiters, compound delimiters, reserved words, and @fas 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 @fa is the character whose name is "LATIN CAPITAL LETTER E", not "GREEK CAPITAL LETTER EPSILON". !corrigendum 3.8(13.1/2) @drepl If a @fa includes the reserved word @b, the type is called an @i type. @dby If a @fa includes the reserved word @b, the type is called an @i type. !corrigendum 3.10.2(12.2/2) @drepl @xinbull in an @fa, the accessibility level of the object or subprogram designated by the associated value (or library level if the value is null);> @dby @xinbull in an @fa, 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) @drepl Certain forms of name (@fas, @fas, @fas, and @fas) include a @fa that is either itself a @fa that denotes some related entity, or an @fa of an access value that designates some related entity. @dby Certain forms of name (@fas, @fas, @fas, and @fas) include a @fa that is either itself a @fa that denotes some related entity, or an @fa of an access value that designates some related entity. !corrigendum 4.3.3(32) @drepl @s9<10 In an @fa, positional notation may only be used with two or more @fas; a single @fa in parentheses is interpreted as a @fa. A @fa, such as (1 => X), may be used to specify an array with a single component.> @dby @s9<10 In an @fa, positional notation may only be used with two or more @fas; a single @fa in parentheses is interpreted as a parenthesized expression. A @fa, such as (1 => X), may be used to specify an array with a single component.> !corrigendum 7.3.1(10.1/2) @drepl If the @fa for a private extension is a @fa, then the reserved word @b shall appear in the @fa if and only if it also appears in the @fa. @dby If the @fa for a private extension is defined by a @fa, then the reserved word @b shall appear in the @fa if and only if it also appears in the @fa. !corrigendum 10.1.1(17) @drepl 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. @dby 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) @drepl A @fa shall be the completion of a @fa or @fa; a @fa shall be the completion of a @fa; a @fa shall be the completion of a @fa. @dby A @fa shall be the completion of a @fa or @fa; a @fa shall be the completion of a task declaration; a @fa shall be the completion of a protected declaration. !corrigendum 12.3(7) @drepl The @i is either the @fa given in a @fa for each formal, or the corresponding @fa or @fa if no @fa 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. @dby The @i is either the @fa given in a @fa for each formal, or the corresponding @fa or @fa if no @fa 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) @drepl The specification of package Wide_Text_IO.Wide_Bounded_IO is the same as that for Text_IO.Bounded_IO, except that any occurrence of Bounded_String is replaced by Wide_Bounded_String, and any occurrence of package Bounded is replaced by Wide_Bounded. The specification of package Wide_Wide_Text_IO.Wide_Bounded_IO is the same as that for Text_IO.Bounded_IO, except that any occurrence of Bounded_String is replaced by Wide_Wide_Bounded_String, and any occurrence of package Bounded is replaced by Wide_Wide_Bounded. @dby The specification of package Wide_Text_IO.Wide_Bounded_IO is the same as that for Text_IO.Bounded_IO, except that any occurrence of Bounded_String is replaced by 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) @drepl 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. @dby 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) @drepl When a @fa appears in a @fa of a @fa the selection of the entry call is attempted, regardless of the specified expiration time. When a @fa appears in a @fa, 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. @dby When a @fa appears in a @fa of a @fa the selection of the entry call is attempted, regardless of the specified expiration time. When a @fa appears in a @fa, 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) @drepl Renamings of Ada 83 Library Units @dby 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). ****************************************************************