Version 1.7 of ais/ai-00211.txt

!topic Renames of inherited abstract subprograms
!reference RM95-8.5.4(8)
!reference RM95-3.9.3(1)
!from Todd Allen 98-11-10 [todd@TAWNY.CCUR.COM]
!keywords subprogram renames, inherited abstract subprograms
!reference 1998-15932.a Todd Allen  1998-11-10
!discussion

If a primitive subprogram for an extension type is a subprogram renaming
declaration and it renames an inherited primitive subprogram of the same
extension type before that inherited primitive subprogram is overridden, then
any call to the renaming subprogram will execute the body of the inherited
primitive subprogram, as opposed to its overriding declaration.

But, if the primitive subprogram of the parent or ancestor type that
corresponds to the inherited primitive subprogram is abstract, then there is
no body to be called.  Similarly, if the primitive subprogram of the parent
or ancestor type is a function with a controlling result, then there exists a
body which could be called, but it will return an object of the wrong type.

Here is an example of the problem with an abstract parent type and primitive:

   package types is
      type t is abstract tagged ...
      procedure p (f : t) is abstract;
   end types;
   package extensions is
      type e is new types.t with ...
      procedure pr (f : e) renames p;                 -- renaming of inherited p
      procedure p  (f : e);
   end extensions;

   ...

   extensions.pr(t2'(...));                           -- What body is called?

Here is an example of the problem with a function with a controlling result:

   package types is
      type t is tagged ...
      function f return t;
   end types;
   package extensions is
      type e is new types.t with ...
      function fr return e renames f;                 -- renaming of inherited f
      function f  return e;
   end extensions;

   ...

   obj : extensions.e := extensions.fr(e'(...));      -- What body is called?

It seems that something in these cases should be illegal, but I am unable to
find any language rules that make it so.  RM95-3.9.3(7) doesn't apply because
it refers to calls to abstract subprograms and neither the renaming
declaration nor the inherited subprogram are considered abstract.
Furthermore, that rule wouldn't really be sufficient, because it would only
detect the problem when a call to the renaming subprogram was made, instead
of at the point of the renaming declaration itself.

We suggest that a renaming of a subprogram inherited from an abstract
primitive subprogram or a primitive subprogram with a controlling result
should be illegal.

--
Todd Allen
Concurrent Computer Corporation

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

!topic Renames of inherited abstract subprograms
!reference RM95-8.5.4(8)
!reference RM95-3.9.3(1)
!from Randy Brukardt 98-11-18 [randy@rrsoftware.com]
!keywords subprogram renames, inherited abstract subprograms
!reference 1998-15932.a Todd Allen  1998-11-10
!reference 1998-15934.a Randy Brukardt  1998-11-18
!discussion

I believe that Todd is asking the wrong question. I think the issue
is simply renaming of abstract subprograms.  Neither 3.9.3 nor
8.5.4 	say anything about that.

I can think only of two reasonable interpretations for renaming of
an abstract subprogram:

-- It is illegal.
-- The renamed subprogram is also abstract.

There certainly is no support in the standard for the first interpretation.

The second interpretation of renaming brings in all of the abstract
baggage, but certainly appears well-defined.

Assuming that the second interpretation is correct, it is clear that
Todd's examples are renaming abstract subprograms, and therefore
the renamed view is abstract. In this case, 3.9.3(3) applies, which makes
declaring the operation illegal, and therefore the renames is illegal.

I will open a ramification AI on this point, since I think the result is not
obvious, and potentially we would want to study whether allowing
renaming of abstract subprograms is worth the work.

                       Randy.

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

From: 	Todd Allen[SMTP:todd@tawny.ccur.com]
Sent: 	Wednesday, November 18, 1998 8:47 AM
To: 	Randy Brukardt
Cc: 	Ada Commentaries
Subject: 	Re: Renames of inherited abstract subprograms

!topic Renames of inherited abstract subprograms
!reference RM95-3.9.3(4-6)
!reference RM95-8.5.4(8)
!reference RM95-3.9.3(1)
!from Todd Allen 98-11-18 [todd@TAWNY.CCUR.COM]
!keywords subprogram renames, inherited abstract subprograms
!reference 1998-15932.a Todd Allen  1998-11-10
!reference 1998-15935.a Todd Allen  1998-11-18
!discussion

I agree that renaming of abstract subprograms is an issue, and it's related
to my commentary.  But it's not quite the point I was trying to make.

If a parent tagged type has an abstract primitive subprogram, the inherited
subprograms for any type extensions are not abstract.  This case is excluded
from 3.9.3(5), and 3.9.3(6) merely says that any subprograms inherited from
abstract subprograms must be overridden, not that they are abstract.  As a
result, neither of the renaming declarations in my examples is renaming an
abstract subprogram.

If the clause 3.9.3(5) were changed to include tagged types, then either of
Randy's interpretations could be applied.  Otherwise, the case of a rename of
a subprogram inherited from an abstract primitive subprogram would have to be
handled separately.

--
Todd Allen
Concurrent Computer Corporation

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

!topic Renames of inherited abstract subprograms
!reference RM95-3.9.3(4-6)
!reference RM95-8.5.4(8)
!reference RM95-3.9.3(1)
!from Randy Brukardt 98-11-18
!keywords subprogram renames, inherited abstract subprograms
!reference 1998-15932.a Todd Allen  1998-11-10
!reference 1998-15934.a Randy Brukardt  1998-11-18
!reference 1998-15935.a Todd Allen  1998-11-18
!reference 1998-15936.a Randy Brukardt  1998-11-18
!discussion

Todd says:

>If a parent tagged type has an abstract primitive subprogram, the inherited
>subprograms for any type extensions are not abstract.  This case is excluded
>from 3.9.3(5), and 3.9.3(6) merely says that any subprograms inherited from
>abstract subprograms must be overridden, not that they are abstract.  As a
>result, neither of the renaming declarations in my examples is renaming an
>abstract subprogram.

I see your point, but I still don't think there is a real problem with the standard.
Assuming that the operative principle for renames is that the new view preserves
the properties of the original view (such as abstractness), we still have no
problem.

In the abstract subprogram case, a renames would create an abstract view.
In Todd's example, a renames would preserve the "must be overridden" property.
Therefore, both of Todd's examples are illegal because the overriding isn't given.
(It's still a ramification.)

					Randy.

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