!standard H.3.1 (8) 98-11-18 AI95-00211/01 !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. Similarly, the "shall be overridden" property of 3.9.3(6) applies to a renamed view. !question 98-11-18 Can an abstract subprogram be renamed? (Yes.) Can a subprogram which must be overridden in the sense of 3.9.3(6) 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? (Yes, but see response.) 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? (Yes, but see response.) 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)). Similarly, it is possible (but not useful) to rename an inherited subprogram which must be overridden because of the rules of 3.9.3(6). The intent of the language is that the "shall be overridden" property also applies to the renamed view. Since the renamed view still must be overridden, such a renaming serves no useful purpose. In the both examples, the renaming is legal. However, both examples are illegal as written since the overridding required by 3.9.3(6) is absent. !appendix 98-11-18 !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. ****************************************************