Version 1.1 of acs/ac-00040.txt

Unformatted version of acs/ac-00040.txt version 1.1
Other versions for file acs/ac-00040.txt

!standard A.5.1(1)          02-06-13 AC95-00040/01
!standard A.5.1(9)
!standard A.5.1(48)
!standard A.10.8(20-23)
!class binding interpretation 02-06-12
!status received no action 02-06-12
!qualifier Omission
!subject Portability issue with non-generic equivalent library packages
!summary
!appendix

!topic portability issue with non-generic equivalent library packages
!reference RM95-A.5.1/{1,9,48}
!reference RM95-A.10.8/20-23
!from Dan Eilers 02-06-12
!discussion

Ada provides nongeneric equivalent packages for several predefined
library units, such as numerics.generic_elementary_functions, and
text_io.integer_io.

For example, RM95 A.10.8/21 shows:

>  with Ada.Text_IO;
>  package Ada.Integer_Text_IO is new Ada.Text_IO.Integer_IO(Integer);


AARM A.5.1/9a explains the purpose as follows:

>  Reason: The nongeneric equivalents are provided to allow the
>  programmer to construct simple mathematical applications without being
>  required to understand and use generics.

However, there is a portability issue due to the implementation permission
provided in A.5.1/48 and A.10.8/23:

>     The nongeneric equivalent packages may, but need not, be actual
>  instantiations of the generic package for the appropriate predefined
>  type.

I presume that the legality of the following code depends on whether
or not an implementation takes advantage of this permission:

    with Ada.Numerics.Generic_Elementary_Functions;
    generic
       with package Elementary_Functions is
         new Ada.Numerics.Generic_Elementary_Functions (<>);
    package pak1 is
    end pak1;

    with pak1;
    with Ada.Numerics.Elementary_Functions;
    package pak2 is new pak1
      (Elementary_Functions => Ada.Numerics.Elementary_Functions);

As far as I can tell, Appendix M does not require documentation
of this portability issue, which leads me to suspect that it may
have been overlooked in granting the implementation permission.

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

From: Robert A. Duff
Sent: Wednesday, June 12, 2002  9:16 PM

> As far as I can tell, Appendix M does not require documentation
> of this portability issue, which leads me to suspect that it may
> have been overlooked in granting the implementation permission.

The fact that permission is given indicates that the designers knew that
a "nongeneric equivalent" is not quite exactly equivalent to an
instantiation.  Otherwise, there would be no such permission,
but just a NOTE or an AARM annotation pointing out the possibility.

You point out one example -- generic formal packages.
I wouldn't be surprised if there were others.

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

From: Robert Dewar
Sent: Thursday, June 13, 2002  1:56 AM

This implementation permission is important, of course I have no objection
adding it to Annex M.

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

Questions? Ask the ACAA Technical Agent