!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
<<reference as: 1998-15927.b W. Wesley Groleau x4923 1998-10-6>>
!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.

****************************************************************

!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 <guerby@gnat.com>, 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.

****************************************************************

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.)]

****************************************************************