Version 1.2 of ais/ai-presentation.txt

Unformatted version of ais/ai-presentation.txt version 1.2
Other versions for file ais/ai-presentation.txt

!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 95-06-25
!recommendation 95-06-25
!wording 95-06-25
!discussion 95-06-25
!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 95-06-25

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 95-06-25

!recommendation 95-06-25

!wording 95-06-25

!discussion 95-06-25

!appendix 95-06-25

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

_____________________________________________________________________
Pascal Leroy                                    +33.1.30.12.09.68
pleroy@rational.com                             +33.1.30.12.09.66 FAX

****************************************************************
!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 95-06-25

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 95-06-25

!recommendation 95-06-25

!wording 95-06-25

!discussion 95-06-25

!appendix 95-06-25

!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".

_____________________________________________________________________
Pascal Leroy                                    +33.1.30.12.09.68
pleroy@rational.com                             +33.1.30.12.09.66 FAX

****************************************************************
!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 95-06-25

!question 95-06-25

!recommendation 95-06-25

!wording 95-06-25

!discussion 95-06-25

!appendix 95-06-25

!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.

_____________________________________________________________________
Pascal Leroy                                    +33.1.30.12.09.68
pleroy@rational.com                             +33.1.30.12.09.66 FAX

****************************************************************
!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 95-06-25

!question 95-06-25

!recommendation 95-06-25

!wording 95-06-25

!discussion 95-06-25

!appendix 95-06-25

!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

_____________________________________________________________________
Pascal Leroy                                    +33.1.30.12.09.68
pleroy@rational.com                             +33.1.30.12.09.66 FAX

****************************************************************
!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 95-06-25

!question 95-06-25

!recommendation 95-06-25

!wording 95-06-25

!discussion 95-06-25

!appendix 95-06-25

!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

_____________________________________________________________________
Pascal Leroy                                    +33.1.30.12.09.68
pleroy@rational.com                             +33.1.30.12.09.66 FAX

****************************************************************
!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 95-06-25

!question 95-06-25

!recommendation 95-06-25

!wording 95-06-25

!discussion 95-06-25

!appendix 95-06-25

!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

_____________________________________________________________________
Pascal Leroy                                    +33.1.30.12.09.68
pleroy@rational.com                             +33.1.30.12.09.66 FAX

****************************************************************
!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 95-06-25

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 95-06-25

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 95-06-25

The incompatibility should be documented in the AARM.

!wording 95-06-25

!discussion 95-06-25

The incompatibility is necessary to avoid generic contract model
problems.

!appendix 95-06-25

!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);

_____________________________________________________________________
Pascal Leroy                                    +33.1.30.12.09.68
pleroy@rational.com                             +33.1.30.12.09.66 FAX

****************************************************************
!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 95-06-25

Change "Bwv" to "BWV".

!question 95-06-25

!recommendation 95-06-25

!wording 95-06-25

!discussion 95-06-25

!appendix 95-06-25

!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...

_____________________________________________________________________
Pascal Leroy                                    +33.1.30.12.09.68
pleroy@rational.com                             +33.1.30.12.09.66 FAX

****************************************************************
!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 95-06-25

!question 95-06-25

!recommendation 95-06-25

!wording 95-06-25

!discussion 95-06-25

!appendix 95-06-25

!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

_____________________________________________________________________
Pascal Leroy                                    +33.1.30.12.09.68
pleroy@rational.com                             +33.1.30.12.09.66 FAX

****************************************************************
!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 95-06-25

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 95-06-25

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 95-06-25

The incompatibility should be documented in the AARM.

!wording 95-06-25

!discussion 95-06-25

???

!appendix 95-06-25

!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;

_____________________________________________________________________
Pascal Leroy                                    +33.1.30.12.09.68
pleroy@rational.com                             +33.1.30.12.09.66 FAX

****************************************************************
!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 95-06-25

!question 95-06-25

!recommendation 95-06-25

!wording 95-06-25

!discussion 95-06-25

!appendix 95-06-25

!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

_____________________________________________________________________
Pascal Leroy                                    +33.1.30.12.09.68
pleroy@rational.com                             +33.1.30.12.09.66 FAX

****************************************************************
!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 95-06-25

!question 95-06-25

!recommendation 95-06-25

!wording 95-06-25

!discussion 95-06-25

!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

_____________________________________________________________________
Pascal Leroy                                    +33.1.30.12.09.68
pleroy@rational.com                             +33.1.30.12.09.66 FAX

****************************************************************
!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 95-06-25

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 95-06-25

!recommendation 95-06-25

!wording 95-06-25

!discussion 95-06-25

!appendix 95-06-25

!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?

_____________________________________________________________________
Pascal Leroy                                    +33.1.30.12.09.68
pleroy@rational.com                             +33.1.30.12.09.66 FAX

****************************************************************
!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 95-06-25

!question 95-06-25

!recommendation 95-06-25

!wording 95-06-25

!discussion 95-06-25

!appendix 95-06-25

!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

_____________________________________________________________________
Pascal Leroy                                    +33.1.30.12.09.68
pleroy@rational.com                             +33.1.30.12.09.66 FAX

****************************************************************
!standard G.1.1    (02)                               95-06-25  AI95-00028/00
!class presentation 95-06-25
!status WG9 approved  96-06-14
!status received 95-06-25
!subject Typo: "pragma" should be in boldface

!summary 95-06-25

!question 95-06-25

!recommendation 95-06-25

!wording 95-06-25

!discussion 95-06-25

!appendix 95-06-25

!section G.1.1(02)
!subject Typo: "pragma" should be in boldface
!reference RM9X-G.1.1(2);5.95
!from Norman Cohen
!reference as: 95-5088.d Norman H. Cohen 95-1-30>>

****************************************************************
!standard 03.06.02 (02)                               95-06-25  AI95-00030/00
!class presentation 95-06-25
!status WG9 approved  96-06-14
!status received 95-06-25
!subject The word "prefix" should be in sans-serif font.

!summary 95-06-25

!question 95-06-25

!recommendation 95-06-25

!wording 95-06-25

!discussion 95-06-25

!appendix 95-06-25

!section 3.6.2(2)
!section 3.7.2(2)
!subject More syntactical categories
!reference RM9X-3.6.2(2);5.95
!reference RM9X-3.7.2(2);5.95
!from Stéphane Barbey
!reference as: 95-5089.a Stephane Barbey 95-1-31>>

Shouldn't the word "prefix" in the paragraph 3.6.2(2) ("The following
attributes are defined for a prefix A that is of an array type ...") be
a syntactical category, like (for instance) in 3.7.2(2) ?

-Stephane

****************************************************************
!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 95-06-25

!question 95-06-25

!recommendation 95-06-25

!wording 95-06-25

!discussion 95-06-25

!appendix 95-06-25

!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.11    (39)                               95-07-27  AI95-00066/00
!class presentation 95-07-27
!status WG9 approved  96-06-14
!status received 95-07-27
!subject Incorrect syntax in example -- remove "limited"

!summary 95-07-27

The reserved word "limited" should be removed from the example in
13.11(39).

!question 95-07-27

!recommendation 95-07-27

!wording 95-07-27

!discussion 95-07-27

!appendix 95-07-27

!section 13.11(39)
!subject Incorrect syntax in example -- remove "limited"
!reference RM95-13.11(39)
!from Bob Duff
!reference as: 95-5214.a Robert A Duff 95-7-8>>
!discussion

The syntax used in this example is incorrect.  The reserved word
"limited" should be removed.  (This dates from an earlier version of Ada
9X, where "limited" was required at that point.)

****************************************************************
!standard D.4      (01)                               95-07-27  AI95-00068/00
!class presentation 95-07-27
!status WG9 approved  96-06-14
!status received 95-07-27
!subject "It also defines [one such policy]{two such policies}."

!summary 95-07-27

D.4 defines *two* language-defined policies.

!question 95-07-27

!recommendation 95-07-27

!wording 95-07-27

!discussion 95-07-27

!appendix 95-07-27

!section D.4(01)
!subject "It also defines [one such policy]{two such policies}."
!reference RM95-D.4(01)
!from Bob Duff
!reference as: 95-5214.c Robert A Duff 95-7-8>>
!discussion

I'm submitting this on behalf of Robert Dewar.

There are two language-defined policies: FIFO_Queuing and
Priority_Queuing.  Perhaps the sentence is meant to imply that this
clause defines Priority_Queuing, whereas FIFO_Queuing is defined in
9.5.3 and 9.7.1.  But then, "Other policies are implementation defined."
would imply that FIFO_Queuing is implementation defined, which is
clearly not true.



****************************************************************
!standard F.3.2    (74)                               95-08-19  AI95-00070/00
!class presentation 95-08-19
!status WG9 approved  96-06-14
!status received 95-08-19
!subject Incorrect Picture String Example

!summary 95-08-19

The picture example in F.3.2(74) should read as follows:

   123456.78  Picture:   "-$**_***_**9.99"
              Result:    "b$***123,456.78"
                        "bFF***123.456,78"  (currency = "FF",
                                             separator = '.',
                                             radix mark = ',')

!question 95-08-19

!recommendation 95-08-19

!wording 95-08-19

!discussion 95-08-19

!appendix 95-08-19

!section F.3.2(74)
!subject Incorrect Picture String Example
!reference RM95-F.3.2(74)
!from Ben Brosgol 95-08-16
!reference as: 95-5259.a Ben Brosgol 95-8-16>>
!discussion

The picture string "-$$$**_***_**9.99" in the referenced paragraph is
invalid, since a floating currency symbol is not allowed in the same
picture string as a zero suppression symbol.  The correction is to have
just one '$' in the picture string, making it a fixed-position currency
symbol, and to remove two leading blanks (indicated by 'b') from the
result strings.  Thus:

   123456.78  Picture:   "-$**_***_**9.99"
              Result:    "b$***123,456.78"
                        "bFF***123.456,78"  (currency = "FF",
                                             separator = '.',
                                             radix mark = ',')

Note that one of the ACVC tests currently relies on the incorrect
version of the example and thus will need to be revised.


****************************************************************
!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 95-07-27

Typo: "by" should be "be".

!question 95-07-27

!recommendation 95-07-27

!wording 95-07-27

!discussion 95-07-27

!appendix 95-07-27

!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 95-07-27

Typo: "its" should be "it's".

!question 95-07-27

!recommendation 95-07-27

!wording 95-07-27

!discussion 95-07-27

!appendix 95-07-27

!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 95-07-27

The AARM example is syntactically illegal.

!question 95-07-27

!recommendation 95-07-27

!wording 95-07-27

!discussion 95-07-27

!appendix 95-07-27

!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;

-- keith@ixi.saic.com ... Keith Shillington (619) 944-1984V -7089fax
-- Select 100% post consumer recycled.  Reduce & Reuse.  Environmental
-- awareness applies to software.  Think deep and act quickly.

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

!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 A        (02)                               95-07-27  AI95-00081/00
!class presentation 95-07-27
!status WG9 approved  96-06-14
!status received 95-07-27
!subject Integer_Text_IO, etc. not listed in A(2)

!summary 95-07-27

Integer_Text_IO and Float_Text_IO should be listed in A(2).

!question 95-07-27

!recommendation 95-07-27

!wording 95-07-27

!discussion 95-07-27

!appendix 95-07-27

!section A(02)
!subject Integer_Text_IO, etc. not listed in A(2)
!reference RM95-A(2)
!reference RM95-A.10.8(20-22)
!reference RM95-A.10.9(32-34)
!from Keith Thompson 95-07-24
!reference as: 95-5231.a Keith Thompson 95-7-24>>
!discussion

Paragraph A(2) is (intended to be) a list of all the predefined library
units in the language.  This list does not include Ada.Integer_Text_IO,
Ada.Float_Text_IO or the equivalent packages for any other predefined
integer and floating-point types.  (Since any other predefined
numeric types are implementation-specific, I wouldn't expect
Ada.Long_Integer_Text_IO, for example, to be listed here.)

Note that Ada.Numerics.Elementary_Functions, a non-generic equivalent
of Ada.Numerics.Generic_Elementary_Functions for type Float, is listed.

****************************************************************
!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 95-09-29

10.2(29) should be added to the index entry for "main subprogram".

!question 95-09-29

!recommendation 95-09-29

!wording 95-09-29

!discussion 95-09-29

!appendix 95-09-29

!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".

****************************************************************
!standard A        (02)                               96-04-04  AI95-00111/00
!class presentation 96-04-04
!status received 96-04-04
!subject Integer_Text_IO, etc. not listed in A(2)

!summary 96-04-04

The packages Ada.Integer_Wide_Text_IO and Ada.Float_Wide_Text_IO should
also be listed in A(2).

!question 96-04-04

!recommendation 96-04-04

!wording 96-04-04

!discussion 96-04-04

!appendix 96-04-04

!section A(02)
!subject Integer_Text_IO, etc. not listed in A(2)
!reference RM95-A(2)
!reference RM95-A.10.8(20-22)
!reference RM95-A.10.9(32-34)
!reference RM95-A.11(3)
!reference AI95-00081
!from Keith Thompson 95-11-02
!reference 95-5380.a Keith Thompson 95-11-2>>
!discussion

The packages Ada.Integer_Wide_Text_IO and Ada.Float_Wide_Text_IO should
also be listed in A(2).

****************************************************************
!standard B.3.2    (49)                               96-05-07  AI95-00142/00
!class presentation 96-05-07
!status received 96-05-07
!subject Incorrect example for Interfaces.C.Pointers

!summary 96-05-07


!question 96-05-07


!recommendation 96-05-07


!wording 96-05-07


!discussion 96-05-07


!appendix 96-05-07

!section B.3.2(49)
!subject Incorrect example for Interfaces.C.Pointers
!reference RM95 B.3.2(49)
!from Pascal Leroy 96-04-29
!reference 96-5528.e Pascal Leroy 96-4-29>>
!discussion

In the example, the usage of "=" in:

   exit when Element = C.Nul;

is illegal unless a use type clause is added for type C.Char.

_____________________________________________________________________
Pascal Leroy                                    +33.1.30.12.09.68
pleroy@rational.com                             +33.1.30.12.09.66 FAX

****************************************************************
!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 96-09-04


!question 96-09-04


!recommendation 96-09-04


!wording 96-09-04


!discussion 96-09-04


!appendix 96-09-04

!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)."

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

!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

_____________________________________________________________________
Pascal Leroy                                    +33.1.30.12.09.68
pleroy@rational.com                             +33.1.30.12.09.66 FAX

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

From: 	Stephane Barbey[SMTP:Stephane.Barbey@di.epfl.ch]
Sent: 	Monday, April 27, 1998 7:58 AM
Subject: 	Accept body

!topic     Accept body
!reference RM95 D.11(18), RM95 J.7.1(16), RM95 J.7.1(20)
!from      Stéphane Barbey 1998-4-27
<<reference as: 1998-15857.a Stephane Barbey  1998-4-27>>

RM95 D.11(18), RM95 J.7.1(16) and RM95, J.7.1(20) mention the concept
of "accept body", which is not defined elsewhere. The ARG should probably
rephrase these paragraphs, although I guess that the priority of this
item is very low.

-Stephane

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

Questions? Ask the ACAA Technical Agent