!standard A.15 (20) 95-06-25 AI95-00005/00 !class presentation 95-06-25 !status WG9 approved 96-06-14 !status received 95-06-25 !subject Incorrect reference in AARM !summary 95-06-25 The index entry for "unspecified" should not point to A.15(20). !question !recommendation !wording !discussion !appendix !section A.15(20) !subject Incorrect reference in AARM !reference AARM-A.15(20);5.95 !from Keith Thompson 94-12-31 !reference as: 94-5049.a Keith Thompson 94-12-31>> !discussion The paragraph in question says 20 {unspecified [partial]} If the external execution environment does not support returning an exit value from a program, then Set_ Exit_Status does nothing. {94-4984.a} In version 5.0 of the AARM, the effect was "not specified by the language", thus the partial definition of "unspecified". This was changed to "does nothing" in 5.7. "{unspecified [partial]}" should be removed. **************************************************************** !standard 03.05.09 (18) 95-06-25 AI95-00008/00 !class presentation 95-06-25 !status received 95-06-25 !subject The implicit range shown in the example is incorrect. !summary In the example where delta is 0.01, the implicit range defined by the digits contraint "digits 6" is -9999.99 .. 9999.99 (according to RM95-3.5.9(18)), not -99.9999 .. 99.9999 as stated in paragraph RM95-3.5.9(18d). !question !recommendation !wording !discussion !appendix !section 3.5.9(18) !subject The implicit range shown in the example is incorrect. !reference RM95-3.5.9(18d);5.95 !from Pascal Leroy !reference as: 95-5068.a Pascal Leroy 95-1-25>> !discussion In the example where delta is 0.01, the implicit range defined by the digits contraints "digits 6" is -9999.99 .. 9999.99 (according to RM95-3.5.9(18)), not -99.9999 .. 99.9999 as stated in paragraph RM95-3.5.9(18d). **************************************************************** !standard 03.09.02 (20) 95-06-25 AI95-00009/00 !class presentation 95-06-25 !status received 95-06-25 !subject Clarify example 3.9.2(20.e). !summary Two comments in 3.9.2(20.e) say "Nondispatching call." This is correct, but could be clarified by saying "Nondispatching call to a dispatching operation." !question !recommendation !wording !discussion !appendix !section 3.9.2(20) !subject All calls in the example are dispatching, but their tag may or may not !reference as: 95-5069.a Pascal Leroy 95-1-25>> be statically determined. !reference RM95-3.9.2(20e);5.95 !from Pascal Leroy !discussion According to the definition of "dispatching call" given in RM95-3.9.2(2) and RM95-3.9.2(1), all the calls in the example are dispatching, contrary to what the comments seem to imply. On the other hand, those that are marked "Nondispatching call" have actually a tag which is not statically determined, and those that are marked "Dispatching call" have a tag which is statically determined. The comments should be changed to talk of "(non) statically determined tags". **************************************************************** !standard 03.09.03 (03) 95-06-25 AI95-00010/00 !class presentation 95-06-25 !status received 95-06-25 !subject Reserved word "abstract" should be in bold. !summary !question !recommendation !wording !discussion !appendix !section 3.9.3(3) !subject Reserved word "abstract" should be in bold. !reference RM95-3.9.3(3e);5.95 !from Pascal Leroy !reference as: 95-5070.a Pascal Leroy 95-1-25>> !discussion In the declaration of procedure Print, the reserved word "abstract" should appear in bold. **************************************************************** !standard 03.09.03 (06) 95-06-25 AI95-00011/00 !class presentation 95-06-25 !status received 95-06-25 !subject T2 inherits an abtract Do_Something, but T{2} is not abtract !summary !question !recommendation !wording !discussion !appendix !section 3.9.3(6) !subject T2 inherits an abtract Do_Something, but T{2} is not abtract !reference RM95-3.9.3(6f);5.95 !from Pascal Leroy !reference as: 95-5071.a Pascal Leroy 95-1-25>> !discussion **************************************************************** !standard 03.10.01 (23) 95-06-25 AI95-00013/00 !class presentation 95-06-25 !status received 95-06-25 !subject even if [it] its completion is deferred !summary !question !recommendation !wording !discussion !appendix !section 3.10.1(23) !subject even if [it] its completion is deferred !reference RM95-3.10.1(23b);5.95 !from Pascal Leroy !reference as: 95-5073.a Pascal Leroy 95-1-25>> !discussion **************************************************************** !standard 04.01.03 (07) 95-06-25 AI95-00015/00 !class presentation 95-06-25 !status received 95-06-25 !subject The protected body may not reference [the] the private components... !summary !question !recommendation !wording !discussion !appendix !section 4.1.3(7) !subject The protected body may not reference [the] the private components... !reference RM95-4.1.2(7a);5.95 !from Pascal Leroy !reference as: 95-5075.a Pascal Leroy 95-1-25>> !discussion **************************************************************** !standard 04.03.03 (16) 95-06-25 AI95-00016/00 !class presentation 95-06-25 !status received 95-06-25 !subject Incompatibility with Ada 83 on applicable index constraints !summary No applicable index constraint is defined for a parameter in a call to a generic formal subprogram; hence, passing an aggregate with an 'others' is illegal in that case. This is an upward incompatibility. !question The following text was legal Ada 83, but is not legal Ada 95: subtype S3 is String (1 .. 3); subtype S5 is String (1 .. 5); generic with function F (The_S3 : in S3) return Integer; package Gp is I : constant Integer := F ((1 => '!', others => '?')); end Gp; function G (The_S5 : in S5) return Integer; package Ip is new Gp (G); Is this incompatibility intended? (Yes.) !recommendation The incompatibility should be documented in the AARM. !wording !discussion The incompatibility is necessary to avoid generic contract model problems. !appendix !section 4.3.3(16) !subject Incompatibility with Ada'83 on applicable index constraints !reference RM95-4.3.3(16);5.95 !from Pascal Leroy !reference as: 95-5076.a Pascal Leroy 95-1-25>> !discussion The following rule is an incompatibility with Ada'83 and should be flagged as such at the end of paragraph 4.3.3, and in the "Changes to Ada" document: "In the case of an explicit_actual_parameter (or default_expression) for a call on a generic formal subprogram, no applicable index constraint is defined". My understanding is that following text was legal Ada'83, but is not legal Ada'95 (I don't complain about that: tightening the contract model is fine, but the incompatibility should be made explicit). subtype S3 is String (1 .. 3); subtype S5 is String (1 .. 5); generic with function F (The_S3 : in S3) return Integer; package Gp is I : constant Integer := F ((1 => '!', others => '?')); end Gp; function G (The_S5 : in S5) return Integer; package Ip is new Gp (G); **************************************************************** !standard 04.04 (15) 95-06-25 AI95-00017/00 !class presentation 95-06-25 !status received 95-06-25 !subject Case of string literal in example !summary Change "Bwv" to "BWV". !question !recommendation !wording !discussion !appendix !section 4.4(15) !subject Case of string literal in example !reference RM95-4.4(15);5.95 !from Pascal Leroy !reference as: 95-5077.a Pascal Leroy 95-1-25>> !discussion In the exmaples of expressions, the string literal "Bwv" would be better written "BWV": this is after all an acronym, and the new rule about case of identifiers should not extend to string literals... **************************************************************** From: Randy Brukardt (Editor) Date: August 30, 2000 There seems to be no point to the above suggestion. The full example is Password(1..3) = "Bwv" I don't see why a password can't be case sensitive (although I hate systems like that!), nor why it would have to be meaningful in any way. The suggestion that this is an acronym makes no sense to me; it doesn't seem to be any of the common acronyms with which I am familar. So I have made no change here. **************************************************************** !standard 04.08 (20) 95-06-25 AI95-00019/00 !class presentation 95-06-25 !status received 95-06-25 !subject ...even though the constraint had no [a]{e}ffect... !summary !question !recommendation !wording !discussion !appendix !section 4.8(20) !subject ...even though the constraint had no [a]{e}ffect... !reference RM95-4.8(20a);5.95 !from Pascal Leroy !reference as: 95-5079.a Pascal Leroy 95-1-25>> !discussion **************************************************************** !standard 05.04 (07) 95-06-25 AI95-00020/00 !class presentation 95-06-25 !status received 95-06-25 !subject Incompability with Ada 83 in legal choices of case statements !summary A function_call is a name. Therefore, if the expression of a case_statement is a function_call, and the result subtype is static, it is illegal to specify a choice outside the bounds of the subtype. This is an upward incompatibility. !question Function calls were not names in Ada 83, but they are names in Ada 95. This means that existing case statements may become illegal since they cover choices outside the range of the function result subtype. For example, the following was legal in Ada 83, but illegal in Ada 95, because it covers the choice 3: subtype S is Integer range 1 .. 2; function F return S; ... case F is when 1 => ... when 2 => ... when 3 => -- Illegal. ... when others => ... end case; Is this incompatibility intended? (Yes.) !recommendation The incompatibility should be documented in the AARM. !wording !discussion ??? !appendix !section 5.4(7) !subject Incompability with Ada'83 in legal choices of case statements !reference RM95-5.4(7);5.95 !from Pascal Leroy !reference as: 95-5080.a Pascal Leroy 95-1-25>> !discussion Because function calls are names, existing case statements may become illegal since they cover choices outside the range of the function result subtype. This should be flagged as an incompatibility with Ada'83 at the end of section 5.4. For instance, the following text (derived from the example given in RM95-5.4(18c)) is illegal in Ada'95, because it covers the choice 3: subtype S is Integer range 1 .. 2; function F return S; ... case F is when 1 => ... when 2 => ... when 3 => ... when others => ... end case; **************************************************************** !topic Change from Ada 83 omitted !reference AARM 5.4(18-18.h) !from Wes Groleau 98 Oct 06 !keywords base type others case <> !discussion In Ada '83, a case statement controlled by a function call in some cases required either an "others" choice or an explicit choice for a value that could never occur. The latter workaround in Ada 83 made for ugly code, but many shops felt it was better than the maintenance risks of "others." Ada 95 improved this situation. The improvement made the workaround illegal. I approve of the change, but would like to point out that it would be more accurate to mention it as an "incompatibility" instead of merely as an "extension." **************************************************************** !standard 08.06 (21) 95-06-25 AI95-00021/00 !class presentation 95-06-25 !status received 95-06-25 !subject ...a universal type that {covers}[includes] the class !summary !question !recommendation !wording !discussion !appendix !section 8.6(21) !subject ...a universal type that {covers}[includes] the class !reference RM95-8.6(21b);5.95 !from Pascal Leroy !reference as: 95-5081.a Pascal Leroy 95-1-25>> !discussion **************************************************************** !standard 08.06 (29) 95-06-25 AI95-00022/00 !class presentation 95-06-25 !status received 95-06-25 !subject Preference for root_integer "[<]{>}" operator !summary !question !recommendation !wording !discussion !appendix 95-06-25 !section 8.6(29) !subject Preference for root_integer "[<]{>}" operator !reference RM95-8.6(29b);5.95 !from Pascal Leroy !reference as: 95-5082.a Pascal Leroy 95-1-25>> !discussion **************************************************************** !standard 11.04 (01) 95-06-25 AI95-00023/00 !class presentation 95-06-25 !status received 95-06-25 !subject Bad reference to an implementation permission !summary Remove "(assuming the implementation has not taken advantage of the Implementation Permission of 11.3)" from 11.4(1.b). There was such a permission in an earlier version, but it is not in the final Standard. !question !recommendation !wording !discussion !appendix !section 11.4(1) !subject Bad reference to an implementation permission !reference RM95-11.4(1b);5.95 !from Pascal Leroy !reference as: 95-5083.a Pascal Leroy 95-1-25>> !discussion The paragraph RM95-11.4(1b) mentions "the Implementation Permission of 11.3", but I cannot find an implementation permission in 11.3. What is the intent of this sentence? **************************************************************** !standard 12 (01) 95-06-25 AI95-00024/00 !class presentation 95-06-25 !status received 95-06-25 !subject ...the role that macros somtime[d]{s} play in other languages. !summary !question !recommendation !wording !discussion !appendix !section 12(1) !subject ...the role that macros somtime[d]{s} play in other languages. !reference RM95-12(1a);5.95 !from Pascal Leroy !reference as: 95-5084.a Pascal Leroy 95-1-25>> !discussion **************************************************************** !standard B.1 (39) 95-06-25 AI95-00052/00 !class presentation 95-06-25 !status WG9 approved 96-06-14 !status received 95-06-25 !subject adainit, adafinal should appear in the index !summary !question !recommendation !wording !discussion !appendix !section B.1(39) !subject adainit, adafinal not indexed !reference RM95-B.1(39) !reference RM95-Index !from Keith Thompson 95-06-01 !reference as: 95-5147.a Keith Thompson 95-6-1>> !discussion This paragraph recommends providing two subprograms with the link names "adainit" and "adafinal". These names do not appear in the index. Also, the fourth and fifth sentences of the paragraph begin with the words "Adainit" and "Adafinal" respectively. Since link names are often case-sensitive, it would be better to rephrase those sentences so the words "adainit" and "adafinal" don't need to be capitalized. **************************************************************** !standard 13.01 (24) 95-07-27 AI95-00075/00 !class presentation 95-07-27 !status received 95-07-27 !subject ... will typically [by]{be} illegal ... !summary Typo: "by" should be "be". !question !recommendation !wording !discussion !appendix !section 13.1(24) !subject ... will typically [by]{be} illegal ... !reference AARM-13.1(24.c) !from Keith Thompson 95-07-13 !reference as: 95-5222.a Keith Thompson 95-7-13>> **************************************************************** !standard 13.01 (24) 95-07-27 AI95-00079/00 !class presentation 95-07-27 !status received 95-07-27 !subject ... we just want to make sure it{'}s feasible. !summary Typo: "its" should be "it's". !question !recommendation !wording !discussion !appendix !section 13.1(24) !subject ... we just want to make sure it{'}s feasible. !reference AARM-13.1(24.a) !from Keith Thompson 95-07-17 !reference as: 95-5227.a Keith Thompson 95-7-18>> **************************************************************** !standard 08.02 (03) 95-07-27 AI95-00080/00 !class presentation 95-07-27 !status received 95-07-27 !subject Illegal syntax in AARM example !summary The AARM example is syntactically illegal. !question !recommendation !wording !discussion !appendix !section 8.2(3) !subject Add:{begin} !reference ARM95-8.2(3e) !from keith@ixi.saic.com !keywords typo !reference as: 95-5229.a Keith Allan Shillington 95-7-20>> !discussion The example is syntatically incorrect as well. with P; package R is package X renames P; {begin} X.Q.I := 17; -- Illegal! end R; **************************************************************** !section 08.02(03) !subject Add:{begin} !reference AARM-08.02 (03e) !reference AI95-00080 !from Pascal Leroy 95-10-20 !reference 95-5359.f Pascal Leroy 95-10-20>> !discussion This AI proposes the following correction to the example: with P; package R is package X renames P; {begin} X.Q.I := 17; -- Illegal! end R; If I still understand something to Ada, a 'begin' is not allowed in a package specification :-) How about: with P; package R is package X renames P; J : Integer := X.Q.I; -- Illegal! end R; **************************************************************** !standard RM-00.00 (00) 95-09-29 AI95-00088/00 !class presentation 95-09-29 !status WG9 approved 96-06-14 !status received 95-09-29 !subject Index bug: main subprogram !summary 10.2(29) should be added to the index entry for "main subprogram". !question !recommendation !wording !discussion !appendix !section RM-00.00(00) !subject Index bug: main subprogram !reference RM95-Index !reference RM95-10.2(7) !reference RM95-10.2(29) !from Keith Thompson 95-08-30 !reference as: 95-5265.a Keith Thompson 95-8-30>> !discussion I was trying to find out what kinds of subprograms must be supported as main subprograms in Ada 95. The index entry for "main subprogram" points to (excuse me, designates 8-)}) paragraph 10.2(7). The information I was really looking for was in 10.2(29). Suggestion: add 10.2(29) to the index entry for "main subprogram". **************************************************************** From: Randy Brukardt (Editor) Date: August 30, 2000 The above suggestion is wrong. 10.2(29) does not define "main subprogram", it just uses it. Moreover, there are quite a few other paragraphs in 10.2 that use "main subprogram" similarly. Should they all be indexed? Finally, the index entry *does* point at the right subclause. Generally, uses of terms are indexed only when very important; index entries primarily serve to point out definitions of terms. **************************************************************** From: Randy Brukardt (Editor) Date: August 30, 2000 I've made the corrections needed to implement all of the numbered presentation issues above in the updated AARM (including the Corrigendum changes). In a few cases, no corrections were done or are anticipated. (These are described in the AI annex. **************************************************************** !standard 04.05.02 (37) 97-08-19 AI95-00154/01 !class presentation 96-09-04 !status received 96-09-04 !subject Miscellaneous Presentation Issues !summary !question !recommendation !wording !discussion !appendix !section 3.8.1(2) !subject The syntax rules of variant_part should be revised !reference RM95-3.8.1(2-5,8) !from Baowen Xu(bwxu@seu.edu.cn) 97-08-13 !keywords variant_part, record, syntax rule !reference 1997-15776.a Xu Bao Wen 1997-8-15>> !discussion In the section 3.8.1, Variant Parts and Discrete Choice, of Ada Reference Manual¡ª¡ªLanguage and Standard Libraries[ARM95], variant parts in records is syntactically defined as following(3.8.1, 2-5): variant_part ::= case discriminant_direct_name is variant { variant } end case; variant ::= when discrete_choice_list => component_list discrete_choice_list ::= discrete_choice {| discrete_choice} discrete_choice ::= expression | discrete_range | others And, in the relevant Lagality Rules(3.8.1, 8), the language imposes the two restrictions on the use of the reserved word others: The discrete choices others shall appear alone in a discrete_choice_list, and such a discrete_choice_list, if it appears, shall be the last one in the enclosing construct. It is quite evident that these two restrictions are both belong to syntax categories, and impossible to be derived from the above- mentioned syntax rules on variant_part. This is inconsistent with the syntax rules of record_definition etc. For examples, from the syntax rules of record_definition (section 3.8, ARM95), record_definition ::= record component_list end record | null record component_list ::= component_item { component_item } | { component_item } variant_part | null; component_item ::= component_declaration | representation_clause component_declaration ::= defining_identifier_list : component_definition [:=default_expression] we can derive the that: * There is a variant_part at most in the component_list of a record_definition; * The variant_part, if it appears, shall be the last one in the enclosing construct. In order to resolve the inconsistency, and to make a more precise description of the syntax rules of the variant_part, I propose that the syntax rules of the variant_part should be revised as follows: variant_part ::= case discriminant_direct_name is variant_list end case; variant_list ::= basic_variant { basic_variant } | { basic_variant } others_variant basic_variant ::= when basic_discrete_choice_list => component_list basic_discrete_choice_list ::= basic_discrete_choice {| basic_discrete_choice} basic_discrete_choice ::= expression | discrete_range others_variant ::= when others => component_list Based on the revised syntax rules, the above- mentioned description on Legality Rules can be removed. Althoug it seems the revision is more complex, its advantages are quite obvious: it not only solves the aforementioned problem, but also simplifies the Legality Rules. Address : Prof. Baowen Xu Dept. of Computer Science & Engineering Southeast University Nanjing 210096 P. R. China Fax Number: 86-25-7712719 E-mail: bwxu@seu.edu.cn **************************************************************** !section 5.4(2) !subject The syntax rules of case statements should be revised !reference RM95-5.4(2-3,5) !from Baowen Xu(bwxu@seu.edu.cn) 97-08-13 !keywords case_statement, syntax rule !reference 1997-15777.a Xu Bao Wen 1997-8-15>> !discussion In the section 5.4, Case statements, of Ada Reference Manual¡ª¡ªLanguage and Standard Libraries[ARM95], case statements is syntactically defined as following(5.4, 2-3): case_statement ::= case expression is case_statement_alternative { case_statement_alternative } end case; case_statement_alternative ::= when discrete_choice_list => sequence_of_statements And, in the relevant Lagality Rules(5.4, 5), the language imposes the two restrictions on the use of the reserved word others: A discrete_choice others, if present, shall appear alone and in the last discrete_choice_list. It is quite evident that these two restrictions are both belong to syntax categories, and impossible to be derived from the above- mentioned syntax rules on case_statement. This is inconsistent with the syntax rules of record_definition etc. For examples, from the syntax rules of record_definition (section 3.8, ARM95), record_definition ::= record component_list end record | null record component_list ::= component_item { component_item } | { component_item } variant_part | null; component_item ::= component_declaration | representation_clause component_declaration ::= defining_identifier_list : component_definition [:=default_expression] we can derive the that: * There is a variant_part at most in the component_list of a record_definition; * The variant_part, if it appears, shall be the last one in the enclosing construct. In order to resolve the inconsistency, and to make a more precise description of the syntax rules of the case_statement, I propose that the syntax rules of the case_statement should be revised as follows: case_statement ::= case expression is case_statement_alternative_list end case; case_statement_alternative_list ::= basic_case_statement_alternative {basic_case_statement_alternative} |{basic_case_statement_alternative} others_case_statement_alternative basic_case_statement_alternative ::= when basic_discrete_choice_list => sequence_of_statements others_case_statement_alternative ::= when others => sequence_of_statements Based on the revised syntax rules, the sentence in the subsection 5.4(5) can be removed:¡°A discrete_choice others, if present, shall appear alone and in the last discrete_choice_list.¡± Althoug it seems the revision is more complex, its advantages are quite obvious: it not only solves the aforementioned problem, but also simplifies the Legality Rules. Address : Prof. Baowen Xu Dept. of Computer Science & Engineering Southeast University Nanjing 210096 P. R. China Fax Number: 86-25-7712719 E-mail: bwxu@seu.edu.cn **************************************************************** !section 11.2(2) !subject The syntax rules of handled_sequence_of_statement should be revised !reference RM95-11.2(2-5,7) !from Baowen Xu(bwxu@seu.edu.cn) 97-08-13 !keywords handled_sequence_of_statement, exception handling, syntax rule !reference 1997-15778.a Xu Bao Wen 1997-8-15>> !discussion In the section 11.2, Exception Handlers, of Ada Reference Manual¡ª¡ª Language and Standard Libraries[ARM95], handled_sequence_of_statement is syntactically defined as following(11.2, 2-5): handled_sequence_of_statements ::= sequence_of_statements [exception exception_handler { exception_handler }] exception_handler ::= when [ choice_parameter_specification: ] exception_choice{exception_choice} => sequence_of_statements choice_parameter_specification ::= defining_identifier exception_choice ::= exception_name | others And, in the relevant Lagality Rules(11.2, 7), the language imposes the two restrictions on the use of the reserved word others: A choice with others is allowed only for the last handler of a handled_sequence_of_statements and as the only choice of that handler. It is quite evident that these two restrictions are both belong to syntax categories, and impossible to be derived from the above- mentioned syntax rules on handled_sequence_of_statement. This is inconsistent with the syntax rules of record_definition etc. For examples, from the syntax rules of record_definition (section 3.8, ARM95), record_definition ::= record component_list end record | null record component_list ::= component_item { component_item } | { component_item } variant_part | null; component_item ::= component_declaration | representation_clause component_declaration ::= defining_identifier_list : component_definition [:=default_expression] we can derive the that: * There is a variant_part at most in the component_list of a record_definition; * The variant_part, if it appears, shall be the last one in the enclosing construct. In order to resolve the inconsistency, and to make a more precise description of the syntax rules of the handled_sequence_of_statement, I propose that the syntax rules of the handled_sequence_of_statement should be revised as follows: handled_sequence_of_statements ::= sequence_of_statements [exception exception_handler_list ] exception_handler_list ::= basic_exception_handler {basic_exception_handler} | {basic_exception_handler} others_exception_handler basic_exception_handler ::= when [ choice_parameter_specification: ] exception_name_list => sequence_of_statements others_exception_handler ::= when [ choice_parameter_specification: ] others => sequence_of_statements choice_parameter_specification ::= defining_identifier exception_name_list ::= exception_name {|exception_name } And the subsection 11.2(7) can be completely deleted, that is, the sentence in the subsection 11.2(7) can be removed:¡°A choice with others is allowed only for the last handler of a handled_sequence_of_statements and as the only choice of that handler.¡± Althoug it seems the revision is more complex, its advantages are quite obvious: it not only solves the aforementioned problem, but also simplifies the Legality Rules. Address : Prof. Baowen Xu Dept. of Computer Science & Engineering Southeast University Nanjing 210096 P. R. China Fax Number: 86-25-7712719 E-mail: bwxu@seu.edu.cn **************************************************************** !section 4.3.1(2) !subject The syntax rules of record_aggregate should be revised !reference RM95-4.3.1(2-5,6) !from Baowen Xu(bwxu@seu.edu.cn) 97-08-13 !keywords record_aggregate, syntax rule !reference 1997-15779.a Xu Bao Wen 1997-8-15>> !discussion In the section 4.3.1, Record Aggregates, of Ada Reference Manual¡ª¡ª Language and Standard Libraries[ARM95], record aggregate is syntactically defined as following(4.3.1, 2-5): record_aggregate ::= ( record_component_association_list ) record_component_association_list ::= record_component_association {, record_component_association } | null record record_component_association ::= [ component_choice_list => ] expression component_choice_list ::= component_selector_name {| component_selector_name } | others And, in the relevant paragraph(4.3.1, 6), the language imposes the following restrictions on the use of the reserved word others: If there is a named association with a component_choice_list of others, it shall come last. It is quite evident that the restriction is belong to syntax categories, and impossible to be derived from the above- mentioned syntax rules on record_aggregate. This is inconsistent with the syntax rules of record_definition etc. For examples, from the syntax rules of record_definition (section 3.8, ARM95), record_definition ::= record component_list end record | null record component_list ::= component_item { component_item } | { component_item } variant_part | null; component_item ::= component_declaration | representation_clause component_declaration ::= defining_identifier_list : component_definition [:=default_expression] we can derive the that: * There is a variant_part at most in the component_list of a record_definition; * The variant_part, if it appears, shall be the last one in the enclosing construct. In order to resolve the inconsistency, and to make a more precise description of the syntax rules of the record_aggregate, I propose that the syntax rules of the record_aggregate should be revised as follows: record_aggregate ::= ( record_component_association_list ) record_component_association_list ::= basic_record_component_association {,basic_record_component_association } | { basic_record_component_association, } others_record_component_association | null record basic_record_component_association ::= [ basic_component_choice_list => ] expression basic_component_choice_list ::= component_selector_name {| component_selector_name } others_record_component_association ::= others => expression Based on the revised syntax rules,the sentence in the subsection 4.3.1(6) can be removed:¡°If there is a named association with a component_choice_list of others, it shall come last.¡± Althoug it seems the revision is more complex, its advantages are quite obvious: it not only solves the aforementioned problem, but also simplifies the description on the syntax. Address : Prof. Baowen Xu Dept. of Computer Science & Engineering Southeast University Nanjing 210096 P. R. China Fax Number: 86-25-7712719 E-mail: bwxu@seu.edu.cn **************************************************************** !section 4.3.3(4) !subject The syntax rules of named_array_aggregate should be revised !reference RM95-4.3.3(4-5) !from Baowen Xu(bwxu@seu.edu.cn) 97-08-13 !keywords record_aggregate, syntax rule !reference 1997-15780.a Xu Bao Wen 1997-8-15>> !discussion In the section 4.3.3, Array Aggregates, of Ada Reference Manual ¡ª¡ª Language and Standard Libraries[ARM95], named record aggregate is syntactically defined as following(4.3.3, 4-5): named_array_aggregate ::= (array_component_association {, array_component_association }) array_component_association ::= discrete_choice_list => expression According to the syntax and the relevant description, we can write several ¡° legal¡± named array aggregates as follows: (1,2=>6.1, others=>4.95, 5,6=>9.0) (1..3=>8.978, 7,9,others=>9.7) However, it is obviously that these two named array aggregates are both illegal! In order to solve this, we should append some sentence similar to the following in therelevant paragraph(such as in paragraph 6,9 or 10): The discrete choice others shall appear alone in a discrete_choice_list,and such a discrete_choice_list, if it appears, shall be the last one in the enclosing construct. But it is quite evident that the restriction is belong to syntax categories, and impossible to be derived from the above- mentioned syntax rules on record_aggregate. This is inconsistent with the syntax rules of record_definition etc. For examples, from the syntax rules of record_definition (section 3.8, ARM95), record_definition ::= record component_list end record | null record component_list ::= component_item { component_item } | { component_item } variant_part | null; component_item ::= component_declaration | representation_clause component_declaration ::= defining_identifier_list : component_definition [:=default_expression] we can derive the that: * There is a variant_part at most in the component_list of a record_definition; * The variant_part, if it appears, shall be the last one in the enclosing construct. In order to resolve the inconsistency, and to make a more precise description of the syntax rules of the named_array_aggregate, I propose that the syntax rules of the named_array_aggregate should be revised as follows: named_array_aggregate ::= (named_array_component_association_list) named_array_component_association_list ::= basic_array_component_association {,basic_array_component_association } | { basic_array_component_association, } others_array_component_association basic_array_component_association ::= basic_discrete_choice_list => expression others_array_component_association ::= others => expression Address : Prof. Baowen Xu Dept. of Computer Science & Engineering Southeast University Nanjing 210096 P. R. China Fax Number: 86-25-7712719 E-mail: bwxu@seu.edu.cn **************************************************************** !section 3.8.1(2) !subject The syntax rules of variant_part should be revised !reference RM95-3.8.1(2-5,8) !from Pascal Leroy 97-08-19 !keywords variant_part, record, syntax rule !reference 1997-15776.a Xu Bao Wen 1997-8-15 !reference 1997-15782.a Pascal Leroy 1997-8-19>> !discussion > In order to resolve the inconsistency, and to make a more precise description > of the syntax rules of the variant_part, I propose that the syntax rules of > the variant_part should be revised as follows: I am not a specialist of parsers, but... While the change that you are suggesting is formally correct, it seems to me that it requires two tokens of look-ahead to determine if a variant is a 'basic' or an 'others' one. LALR(1) parser generators are much more common than LALR(2), so it's a good idea to write the grammar so that it requires only one token of look-ahead. I believe that's why the RM formulation was choosen. Pascal **************************************************************** From: Randy Brukardt (Editor) Date: August 30, 2000 The syntax changes proposed by Prof. Baowen Xu are clearly out-of-scope and (for the reason mentioned by Pascal) counter-productive. They will be ignored. His other comments are also incorrect (the "others" requirement for an array aggregate is actually found in 3.8.1). So these comments will be ignored. **************************************************************** From: Dan Eilers Sent: Wednesday, October 18, 2000 8:22 PM !topic doubled words !reference RM95-3.9.2(9/1) !reference RM95-9.3(6) !reference RM95-A.10.7(8) !discussion RM95-3.9.2(9/1) "then the then the" RM95-9.3(6) "an an" RM95-A.10.7(8) "the the" [Editor's note: The first version of the revised RM also contained the following errors: RM95-3.10.2(27.1/1) "covered by the D" -> "covered by D" RM95-E.2.3(9/1) "to of an" -> "to an" these all have been fixed in the second version (the one with the "unofficial" title page.] **************************************************************** From: Randy Brukardt (Editor) Date: August 30, 2000 Items below this item have *not* been handled in the updated AARM. That can be accomplished at a future time. **************************************************************** From: Dan Eilers Sent: Tuesday, November 21, 2000 8:53 PM !topic typo in revised RM !reference RM95-9.6(26/1) !discussion There is an extra space after "Year" in 9.6(26/1) # This exception is also raised by the functions Year , Month, Day, and # Seconds and the procedure Split if the year number of the given date # is outside of the range of the subtype Year_Number. **************************************************************** From: Randy Brukardt Sent: Wednesday, December 6, 2000 8:53 PM The discussion saved in AC-00002 points out that the conversions mentioned in paragraphs 3.5.4(9), 3.5.7(11), and 3.5.9(14, 16) are not "implicit conversions", as "implicit conversions" happen as part of overload resolution. However, these paragraphs are indexed under "implicit subtype conversion". Those index entries should be removed, or changed to "subtype conversion, neither implicit or explicit". [My solution: Add an AARM annotation to each of these paragraphs: To be honest: The "conversion" mentioned above is not an implicit subtype conversion (which is something that happens at overload resolution, see 4.6). Therefore, the freezing rules are not invoked on the type (which is important so that representation items can be given for the type). {Index: subtype conversion, neither implicit or explicit} Delete the existing index entry. (The result is that the RM would not index these paragraphs, while the AARM would have this funny index entry.)] **************************************************************** From: Randy Brukardt (Editor) Date: March 22, 2001 (From an FRT discussion:) The error (in 7.6.1(16/1)) is in the merged RM, where I failed to include the change of "operation" to "statement". Keep in mind that the merged RM is unofficial; the Corrigendum is the official document. If in doubt, look at the source. Sigh. **************************************************************** From: Dirk Craeynest Sent: Thursday, April 05, 2001 10:07 AM !topic Still alligators in RM95 Index !reference RM95-Index;pp.535+543 (with COR.1:2000) !from Dirk Craeynest 01-04-05 !discussion Although this was already reported during the 9X project, "ISO/IEC 8652:1995(E) with COR.1:2000" still has two alligators hiding in the Index. A copy of the old report: = !topic remove alligators from RM9X Index = !reference RM9X-Index;5.7 = !reference 93-3416.a Stef Van Vlierberghe 93-12-8 = !reference 94-4515.a Dan Eilers 94-7-25 = !from Dan Eilers 94-11-05 = <> = !discussion = = >constructor = > See initialized alligator 4.8(4) = = >heap management = > See also alligator 4.8(1) = = -- Dan Eilers As far as I can see on the http://www.ada-auth.org/ais.html site there is no reference anymore to this in the current Ada Issues Database. **************************************************************** From: Randy Brukardt Sent: Thursday, April 05, 2001 2:01 PM The comment you reference predates the Ada 95 ARG, so of course it is not included in any AI. Since my mind-reading helmet is in the shop, I failed to notice and fix this problem. I only spent time fixing problems I knew about. I've added this to the presentation issues AI, so might get handled next time. **************************************************************** From: Robert A Duff Sent: Thursday, April 05, 2001 4:20 PM > Although this was already reported during the 9X project, "ISO/IEC > 8652:1995(E) with COR.1:2000" still has two alligators hiding in the > Index. A history lesson: *I* put those "alligators" in the index, and I deliberately ignored Dan Eilers' gripe about it during the 9X design. The Swiss DR's then complained that if alligators are in the index, then squirrels should be, too, so I obliged (only in the AARM). In response to their complaint, I added this to the AARM index: squirrel away included in fairness to alligators 8.5.4(8) which refers to: 8.g Thus a renaming allows one to squirrel away a copy of an inherited or predefined subprogram before later overriding it. {squirrel away (included in fairness to alligators)} A pre-1983 Ada compiler at Intermetrics (written in Simula-67) had a data type called Alligator_Exp to represent "new ...", and that's where I got the idea for this silly joke. The Index is not "normative", and can therefore contain jokes. So don't go erasing my jokes, no matter how unfunny they may be. **************************************************************** From: Randy Brukardt Sent: Thursday, April 05, 2001 4:41 PM The problem here is that these references are in place of "allocators", not in addition to them. So they are potentially harmful on that basis (there isn't a reference to allocators at either of these points in the index). **************************************************************** From: Michael Yoder Sent: Friday, April 06, 2001 1:01 PM So, you're saying this could come back to bite us? **************************************************************** From: Randy Brukardt (Editor) Date: April 6, 2001 Items below this item have *not* been handled in the updated AARM or RM. That can be accomplished at a future time. (This second line reflects the "Springer" version of the documents.) **************************************************************** !section 4.5.2(37) !subject Illegal string comparison in RM95-4.5.2 example !reference RM95-4.5.2(37) !from Laurent Guerby 96-06-30 !keywords example !reference 96-5620.a Laurent Guerby 96-6-30>> !discussion "" < "A" and "A" < "Aa" -- True "Aa" < "B" and "A" < "A " -- True are both illegal (ambiguous between Wide_String and String). -- Laurent Guerby , Team Ada. "Use the Source, Luke. The Source will be with you, always (GPL)." **************************************************************** From: Dr Steve Sangwine [S.J.Sangwine@TALK21.COM] Sent: Wednesday, December 15, 1999 9:12 AM To: ADA-COMMENT@ACM.ORG Subject: [Ada-Comment] LRM obscure on generic formal types with unknown discriminants !topic LRM obscure on generic formal types with unknown discriminants !reference RM95-12.5(2) !reference RM95-12.5(10) !reference RM95-12.5.1(6) !from Stephen J. Sangwine (S.Sangwine@IEEE.org) 99-12-15 !definite indefinite !discussion A private formal type in a generic package can be declared as type X(<>) is [limited] private. This permits the actual subtype to be indefinite (example an unconstrained array subtype) but does not allow the body to use the formal type in a context that would require a definite subtype (example object declaration). The LRM is unclear on this whereas the Ada 95 Rationale (Intermetrics, Inc., January 1995) gives a very clear discussion at Section 12.1 (The Contract Model). Places where the LRM is lacking in clarity include the index where '[D|d]efinite' refers only to 12.5.1(23), K(50) and 3.3(23) and not 12.5.1(6). Note 8 at 12.5(10) is unhelpful and as a minimum it would be useful if a short explanation was inserted here along the lines of that given in the Rationale. **************************************************************** !topic : Typographical error !reference : RM95-4.1.3(17) !from : John S. Murphy 02-04-11 !keywords : selected components, examples, 4.1.3, 9.4, 9.1 !discussion In the paragraph 17 of section 4.1.3 of the RM95 the example Pool(K).Write contains a reference to section 9.4. I believe this reference should be to section 9.1. Section 9.4 does not contain a declaration of Pool whereas section 9.1 does. ****************************************************************