Version 1.3 of si99s/si99-0061-1.txt

Unformatted version of si99s/si99-0061-1.txt version 1.3
Other versions for file si99s/si99-0061-1.txt

!standard 15.24          10-03-04 SI99-0061-1/02
!class ramification 10-01-26
!status ARG Approved 7-0-2 10-02-26
!status work item 10-01-26
!status received 09-11-11
!priority Medium
!difficulty Easy
!qualifier Omission
!subject Gap in Asis.Declarations.Corresponding_Declaration
!summary
!question
15.24 says:
If an inherited subprogram declaration is given, the specification returned is the one for the user-defined subprogram from which the argument was ultimately inherited.
In addition, it is defined to only return declarations.
Consider:
type E is new Float;
function "=" (A, B : E) return Boolean is begin return abs (A - B) < 0.01; end "=";
type DE is new E;
Type DE inherits "=" from the body declaration of "=" for E. What should be returned by Corresponding_Declaration when applied to this inherited subprogram? (Nil_Element).
The only possibility is the body declaration, but this conflicts with the definition of the returned kinds list for Corresponding_Declaration.
!response
The wording of 15.24 also says:
Returns Nil_Element if no explicit specification exists, or the declaration is the proper body of a subunit.
That surely applies to this case. It would be amazingly strange if the Corresponding_Declaration for "=" on E returns Nil_Element, but "=" on DE returned some body.
In addition, it appears that the query Corresponding_Subprogram_Derivation was provided to provide the answer to this question if the caller wants to get an answer whether or not the item is inherited from a body. Thus, there is no missing functionality in ASIS for this case.
!discussion
One could argue that the design of this function is wrong, in that the body of "=" acts as its declaration, and thus it should be returned. But that was a mistake made long ago, and attempting to fix it would add incompatibilities to ASIS functions. The existence of Corresponding_Subprogram_Derivation makes it unnecessary to make any change.
!appendix

From: Sergey I. Rybin
Sent: Wednesday, November 11, 2009  1:41 PM

15.24 says:

   If an inherited subprogram declaration is given, the specification returned
   is the one for the user-defined subprogram from which the argument was
   ultimately inherited.

and it defines the list of returned kinds as

        Not_A_Declaration
        A_Function_Declaration
        A_Function_Renaming_Declaration
        A_Generic_Function_Declaration
        A_Generic_Package_Declaration
        A_Generic_Procedure_Declaration
        A_Package_Declaration
        A_Package_Renaming_Declaration
        A_Procedure_Declaration
        A_Procedure_Renaming_Declaration
        A_Single_Task_Declaration
        A_Task_Type_Declaration
        A_Protected_Type_Declaration
        A_Single_Protected_Declaration
        An_Entry_Declaration

And now consider:

   type E is new Float;

   function "=" (A, B : E) return Boolean is
   begin
      return abs (A - B) < 0.01;
   end "=";

   type DE is new E;


Type DE inherits "=" from the *body* declaration of "=" for E, The question is -
what should be returned by Corresponding_Declaration when applied to this
inherited subprograms The only reasonable possibility is the body declaration,
but this contradicts with the definition of the returned kinds list for
Corresponding_Declaration.

It seems that the list of returned Declaration_Kinds of this query should be
extended by

       A_Procedure_Body_Declaration
       A_Function_Body_Declaration

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

From: Randy Brukardt
Sent: Tuesday, January 26, 2010  11:32 PM

I just finished an SI for a question Sergey submitted back in November. After
study, I believe he is wrong. As such, I wrote up the SI as a ramification.
Following is the meat of the SI (SI99-0061-1):

[Following was version /01 of the SI. - ED]

---

Before I discovered Corresponding_Subprogram_Derivation, I was going to
recommend using the semantic subsystem. But it does not appear to expose the
inheritance relationship. I find this weird: it has queries about ancestors,
about primitiveness, and about overriding, but not about inheritance. One could
use the three things I mentioned to figure out the inheritance relationship, but
it would be a pain. Inheritance is one thing I would definitely expect to find
in the semantic interface - I find it odd that it does not provide such
interfaces -- especially as it provides overriding interfaces. (You *can* come
back to the syntactic interface and use Corresponding_Subprogram_Derivation, but
that would seem to require rapidly going back and forth between the subsystems.)

If we wanted to add them, I would suggest using the
Is_Overriding/Overridden_Declarations interface as an example; possibly add
Is_Inherited/Inherited_from_Declarations directly into 23.2.8. (If there is any
support for this idea, I'll just add it to the existing SI99-0054-1.)

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

From: Jean-Pierre Rosen
Sent: Thursday, January 28, 2010  4:01 AM

> I just finished an SI for a question Sergey submitted back in November.
> After study, I believe he is wrong. As such, I wrote up the SI as a 
> ramification. Following is the meat of the SI (SI99-0061-1):
> 
[...]
I agree with your analysis, but I wonder why Sergey thought differently...

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

Questions? Ask the ACAA Technical Agent