Version 1.2 of ais/ai-00211.txt

Unformatted version of ais/ai-00211.txt version 1.2
Other versions for file ais/ai-00211.txt
!standard H.3.1 (8)          98-11-18 AI95-00211/00
!class ramification 98-11-18
!status work item 98-11-18
!priority Medium
!difficulty Easy
!subject Can an abstract subprogram be renamed?
!summary 98-11-18
An abstract subprogram can be renamed, and the renamed view is also abstract. Such a renaming must appear in a place where the declaration of an abstract subprogram would be legal.
!question 98-11-18
Can an abstract subprogram be renamed? (Yes.)
Consider an example with an abstract parent type and primitive. 8.5.4(8) says that the renaming uses the original inherited subprogram, not the overriding version.
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 -- Legal? (No.) procedure p (f : e); end extensions;
A similar example can be constructed 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 -- Legal? (No.) function f return e; end extensions;
!response 98-11-18
The intent of the language is that an abstract subprogram can be renamed, and the renamed view is also abstract. All of the rules about declaring abstract subprograms apply at the point of the renaming (in particular, 3.9.3(3)).
In the first example, the renaming is illegal by 3.9.3(3), as a subprogram primitive for a non-abstract tagged type cannot be abstract.
In the second example, the renaming is legal, but useless, as an overriding version must be provided as specified in 3.9.3(6).
!appendix

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

****************************************************
Questions? Ask the ACAA Technical Agent