Version 1.8 of ais/ai-00192.txt

Unformatted version of ais/ai-00192.txt version 1.8
Other versions for file ais/ai-00192.txt

!standard 06.03 (04)          99-10-07 AI95-00192/05
!standard 10.01.04 (04)
!class binding interpretation 98-09-10
!status Corrigendum 2000 99-07-08
!status WG9 approved 99-06-12
!status ARG approved 98-10-08 (7-0-0)
!status work item 98-09-10
!status received 97-08-19
!priority Medium
!difficulty Medium
!qualifier Error
!subject A library subprogram_body should replace, not complete, an instance
!summary
A library subprogram body can be interpreted as the completion of a generic subprogram or of a subprogram that is not an instance of a generic subprogram but not as the completion of an instance of a generic subprogram.
!question
Can a library subprogram body ever complete an existing generic instance? (No.)
!recommendation
A library subprogram body never completes an existing generic instance. (It replaces it.)
!wording
10.1.4(4) should read
If a library_unit_body that is a subprogram_body is submitted to the compiler, it is interpreted only as a completion if a library_unit_declaration for a subprogram other than an instance of a generic subprogram or for a generic subprogram with the same defining_program_unit_name already exists in the environment ...
!discussion
It is a general principle in Ada 95 (as in Ada 83) that a library generic instance be considered as a single lump and can not be considered decomposed into specification and body for the purposes of completion or replacement.
Suppose we compile
generic procedure GP;
procedure GP is ... end GP;
with GP; procedure P is new GP;
and then submit
procedure P is begin ... end P;
The consequence is that the newly submitted procedure P completely replaces the instance P. It does not act as a new completion for the instance specification and thereby just replace the notional body of the instance.
However, this intention was not clear in the Ada 83 RM but was clarified by AI83-199 and AI83-266. In particular, the latter says
"After instantiating a generic subprogram as a library unit, any attempt to compile a subprogram body having the same identifier as that of the library unit instantiation causes the instantiation to be deleted from the library and replaced with the new library unit subprogram."
It was the intention that the behaviour in Ada 95 be the same in this respect. However, there was a change of wording between Ada 83 and Ada 95 which might have been the source of confusion. In Ada 83 the term subprogram did not include an instance whereas in Ada 95 the term subprogram does include an instance.
In RM95, 10.1.4(4) says
"If a library_unit_body that is a subprogram_body is submitted to the compiler, it is interpreted only as a completion if a library_unit_declaration for a subprogram or a generic subprogram with the same defining_program_unit_name already exists in the environment ... "
This incorrectly uses the term "subprogram" where it intended to exclude the case of an instance and so should have said "a subprogram that is not an instance".
!corrigendum 10.01.04(4)
Replace the paragraph:
If a library_unit_body that is a subprogram_body is submitted to the compiler, it is interpreted only as a completion if a library_unit_declaration for a subprogram or a generic subprogram with the same defining_program_unit_name already exists in the environment (even if the profile of the body is not type conformant with that of the declaration); otherwise the subprogram_body is interpreted as both the declaration and body of a library subprogram.
by:
If a library_unit_body that is a subprogram_body is submitted to the compiler, it is interpreted only as a completion if a library_unit_declaration with the same defining_unit_name already exists in the environment for a subprogram other than an instance of a generic subprogram or for a generic subprogram (even if the profile of the body is not type conformant with that of the declaration); otherwise the subprogram_body is interpreted as both the declaration and body of a library subprogram.
!ACATS test
The test prompting the question (CA1020D) was withdrawn. It has been reinstated with a new number (CA14028).
!appendix

!section 6.3(4)
!subject A library subprgram_body should replace, not complete, an instance
!reference RM95-6.3(4), 10.1.4(4), 12.3(13)
!from Dan Lehman 97-05-30
!keywords library subprogram_body, completion
!reference 1997-15754.a Dan Lehman 1997-5-30>>
!discussion

   An implementer petitioning for deviation on an ACVC test program has
found an unintended difference between the Ada 83 & 95 standards.  As shown
below, RM95-10.1.4(4) unintentionally contradicts RM83 and AI83-199/266, as
it calls a library subprogram_body a completion of a library instance which
is thus illegal by RM95-6.3(4), whereas Ada 83 treated it as a library-unit
replacement (and legal).

  I think that the wording in 10.1.4(4) should be revised to specify the
syntactic items "subprogram_" & "generic_declaration" where it uses the term
"library_unit_declaration"; alternatively, Tuck recommends that that wording
qualify the replaceable subprograms as "non-instance".

   Tuck writes:

| The "intent" as documented in AARM 10.1.4(4.a-4.b) is that a subprogram
| body will replace a generic instantiation.  The "meta rule" was
| that a subprogram body would replace anything for which it could
| not be a legal completion, presuming you ignore any parameter/result
| profile mismatch.
|
| The 10.1.4(4) wording should be fixed to say "... is interpreted only as a
| completion if a library_unit_declaration for a {non-instance} subprogram
| or {for} a generic subprogram with the same ..."

---Dan
------- *
--------------------------------------------------------------------------

Reference:  ca1020d  [ACVC 1.x, 2.x--all since '85]

Summary:

   The test ca1020d declares a number of subprograms as generic
   instantiations and then attempts to replace them with a number of
   subprograms declared as subprogram_body's.  The test expects the
   replacement to occur, and fails otherwise.  However, the RM appears to
   require the subprogram_body's to be rejected, not to replace the
   generic instantiations.

Discussion:

ACVC test file ca1020d0 declares a number of generics and the following
compilation units as generic instantiations:

   ca1020d_proc1 (instantiation of genproc_ca1020d "returning" value 1)
   ca1020d_func2 (instantiation of genfunc_ca1020d returning   value 2)
   ca1020d_proc3 (instantiation of genproc_ca1020d "returning" value 3)
   ca1020d_func3 (instantiation of genfunc_ca1020d returning   value 3)

File ca1020d1 provides the following library subprogram bodies, intending
that they replace the previously listed subprogram instantiations:

   ca1020d_proc1 (subprogram body "returning" value 3)
   ca1020d_func2 (subprogram body returning   value 4)
   ca1020d_proc3 (subprogram body "returning" values false and 6)
   ca1020d_func3 (subprogram body returning   value false)

However, the RM appears to require that these items be rejected.
RM95-10.1.4(4) says: "If a library_unit_body that is a subprogram_body is
submitted to the compiler, it is interpreted only as a completion if a
library_unit_declaration for a subprogram or generic subprogram with
the same defining_program_unit_name already exists in the environment
(even if the profile of the body is not type conformant with that of
the declaration); ..."

Further, RM95-12.3(13) says "An instance of a generic package is a
package, that of a generic procedure is a procedure, and that of a
generic function is a function."

So, the four generic instantiations declared in ca1020d0 are
library_unit_declarations and subprograms, and each has the same
defining_program_unit_name as a subprogram_body counterpart in
ca1020d1.  For this reason, the subprogram bodies in ca1020d1 should be
considered completions.

RM95-6.3(4) says: "If the body is a completion, it shall be the completion
of a subprogram_declaration or generic_subprogram_declaration."
However, the visible declarations are all generic_instantiations,
so these completions must be considered illegal and rejected.

Similarly, in ca1020d2, the following library subprogram bodies are
provided:

   ca1020d_proc3 (subprogram body "returning" value 4)
   ca1020d_func3 (subprogram body returning   value 7)

For the same reasons stated above, these items are considered completions,
and those completions are illegal.

So, finally, we are left with the original instantiations defined in
ca1020d0 (and the unrelated declarations of ca1020d_proc5 and
ca1020d_func22 in ca1020d2).  The main subprogram ca1020d3m
expects the values 3, 4, 5, 2, 4, and 7.  But, it actually
receives the values 1, 2, 5, 2, 3, and 3.

On the basis of these references, we believe that the test ca1020d
should be withdrawn.

===========================================================================

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

Questions? Ask the ACAA Technical Agent