* Renaming an abstract function @ 2001-11-15 23:52 Nick Roberts 2001-11-16 14:52 ` Stephen Leake 0 siblings, 1 reply; 11+ messages in thread From: Nick Roberts @ 2001-11-15 23:52 UTC (permalink / raw) When given the program: package Test1 is type T is abstract tagged limited private; function P (X, Y: in T) return T is abstract; function "*" (A, B: in T) return T renames P; -- error line private type T is abstract tagged limited null record; end; GNAT 3.12p on Windows 95 returns the error message: function that returns abstract type must be abstract Is this a bug in: (a) GNAT; (b) the RM95; or (c) my brain? Full detailed explanation welcome (if applicable). -- Best wishes, Nick Roberts ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Renaming an abstract function 2001-11-15 23:52 Renaming an abstract function Nick Roberts @ 2001-11-16 14:52 ` Stephen Leake 2001-11-17 3:08 ` Adam Beneschan 0 siblings, 1 reply; 11+ messages in thread From: Stephen Leake @ 2001-11-16 14:52 UTC (permalink / raw) "Nick Roberts" <nickroberts@adaos.worldonline.co.uk> writes: > When given the program: > > package Test1 is > type T is abstract tagged limited private; > function P (X, Y: in T) return T is abstract; > function "*" (A, B: in T) return T renames P; -- error line > private > type T is abstract tagged limited null record; > end; > > GNAT 3.12p on Windows 95 returns the error message: > > function that returns abstract type must be abstract > > Is this a bug in: (a) GNAT; (b) the RM95; or (c) my brain? Same error in gnat 3.14 (you should at least upgrade to 3.13p). RM 8.5.4 (2) says: 2. subprogram_renaming_declaration ::= subprogram_specification renames callable_entity_name; The term "callable_entity_name" is not mentioned elsewhere in the reference manual, which I find odd. However, just taking the literal English meaning, an abstract function is _not_ callable, so it appears that you cannot rename an abstract function. Too bad; it would be nice here (assuming "P" is a multiplication operator :). On the other hand, it could be confusing. Is the renamed function also inherited (which is what you would want)? RM 3.2.3 says: 2. The primitive subprograms of a specific type are defined as follows: 3. The predefined operators of the type, see *Note 4.5::, 4. For a derived type, the inherited, see *Note 3.4::, user-defined subprograms; 5. For an enumeration type, the enumeration literals (which are considered parameterless functions - see *Note 3.5.1::.); 6. For a specific type declared immediately within a package_specification, any subprograms (in addition to the enumeration literals) that are explicitly declared immediately within the same package_specification and that operate on the type; I don't think a renaming declaration meets this definition, so they are not inherited. So you have to choose either "P" or "*" for the primitive operation, and provide the other name via renaming as needed for each derived type. It depends on which name is more likely to be needed. I guess my answer to your question is (c) :). -- -- Stephe ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Renaming an abstract function 2001-11-16 14:52 ` Stephen Leake @ 2001-11-17 3:08 ` Adam Beneschan 2001-11-17 17:47 ` Egil Harald Hoevik ` (2 more replies) 0 siblings, 3 replies; 11+ messages in thread From: Adam Beneschan @ 2001-11-17 3:08 UTC (permalink / raw) Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote in message news:<uvggau5ro.fsf@gsfc.nasa.gov>... > "Nick Roberts" <nickroberts@adaos.worldonline.co.uk> writes: > > > When given the program: > > > > package Test1 is > > type T is abstract tagged limited private; > > function P (X, Y: in T) return T is abstract; > > function "*" (A, B: in T) return T renames P; -- error line > > private > > type T is abstract tagged limited null record; > > end; > > > > GNAT 3.12p on Windows 95 returns the error message: > > > > function that returns abstract type must be abstract > > > > Is this a bug in: (a) GNAT; (b) the RM95; or (c) my brain? > > Same error in gnat 3.14 (you should at least upgrade to 3.13p). > > RM 8.5.4 (2) says: > > 2. subprogram_renaming_declaration ::= > subprogram_specification renames callable_entity_name; > > The term "callable_entity_name" is not mentioned elsewhere in the > reference manual, which I find odd. Note that "callable_entity" is in italics, while "name" is not. In RM notation, that means that the language expects the syntax of a "name" (defined in 4.1), while "callable_entity" is a description that tells you what the name has to represent. I guess if you're searching a text file version of the RM, there's probably no indication that part of it is in italics. "callable entity" is easily found in the index. A "callable entity" is defined (in 6(2)) to be a subprogram or entry. Thus an abstract subprogram is a callable entity even though you can't really call it. I don't see any prohibition on renaming an abstract subprogram. However, renaming subprograms don't quite take on all the characteristics of the subprograms they rename; see 8.5.4(12) for instance. I suspect that has something to do with why renaming an abstract subprogram could lead to an error, but I don't have time right this minute to look into it further. -- Adam ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Renaming an abstract function 2001-11-17 3:08 ` Adam Beneschan @ 2001-11-17 17:47 ` Egil Harald Hoevik 2001-11-17 18:33 ` Stephen Leake 2001-11-17 22:00 ` Mark Biggar 2 siblings, 0 replies; 11+ messages in thread From: Egil Harald Hoevik @ 2001-11-17 17:47 UTC (permalink / raw) Adam Beneschan wrote: > <snip> > A "callable entity" is defined (in 6(2)) to be a subprogram or entry. > Thus an abstract subprogram is a callable entity even though you can't > really call it. > RM 6 (1): "...The definition of a subprogram can be given in two parts: a subprogram declaration defining its interface, and a subprogram_body defining its execution..." So, a subprogram (callable entity) requires a body (callable construct), while an abstract subprogram does not, and the RM distinguishes between the two: RM 6.1 (2-3): subprogram_declaration ::= subprogram_specification; abstract_subprogram_declaration ::= subprogram_specification is abstract; > I don't see any prohibition on renaming an abstract subprogram. > However, renaming subprograms don't quite take on all the > characteristics of the subprograms they rename; see 8.5.4(12) for > instance. I suspect that has something to do with why renaming an > abstract subprogram could lead to an error, but I don't have time > right this minute to look into it further. > > -- Adam Well, RM 8.5.4 (2): subprogram_renaming_declaration ::= subprogram_specification renames callable_entity_name; If renaming an abstract subprogram were allowed, I, at least, would think that the language would explicitly require the keyword 'abstract' in the renaming declaration (which it does not). ~egilhh -- "What I seek is to serve, with my feeble capacity, truth and justice at the risk of pleasing no-one." Albert Einstein. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Renaming an abstract function 2001-11-17 3:08 ` Adam Beneschan 2001-11-17 17:47 ` Egil Harald Hoevik @ 2001-11-17 18:33 ` Stephen Leake 2001-11-17 22:00 ` Mark Biggar 2 siblings, 0 replies; 11+ messages in thread From: Stephen Leake @ 2001-11-17 18:33 UTC (permalink / raw) adam@irvine.com (Adam Beneschan) writes: > Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote in message news:<uvggau5ro.fsf@gsfc.nasa.gov>... > > "Nick Roberts" <nickroberts@adaos.worldonline.co.uk> writes: > > > > > When given the program: > > > > > > package Test1 is > > > type T is abstract tagged limited private; > > > function P (X, Y: in T) return T is abstract; > > > function "*" (A, B: in T) return T renames P; -- error line > > > private > > > type T is abstract tagged limited null record; > > > end; > > > > > > GNAT 3.12p on Windows 95 returns the error message: > > > > > > function that returns abstract type must be abstract > > > > > > Is this a bug in: (a) GNAT; (b) the RM95; or (c) my brain? > > > > Same error in gnat 3.14 (you should at least upgrade to 3.13p). > > > > RM 8.5.4 (2) says: > > > > 2. subprogram_renaming_declaration ::= > > subprogram_specification renames callable_entity_name; > > > > The term "callable_entity_name" is not mentioned elsewhere in the > > reference manual, which I find odd. > > Note that "callable_entity" is in italics, while "name" is not. Well, not in the info version :). Guess there's a use for html, after all :). > In RM notation, that means that the language expects the syntax of a > "name" (defined in 4.1), while "callable_entity" is a description > that tells you what the name has to represent. I guess if you're > searching a text file version of the RM, there's probably no > indication that part of it is in italics. Yes; "info format" is ASCII with hyperlinks. Nice for reading from Emacs. But it does lose the italics. Hmm, Emacs 21.1 can probably do a better job of displaying the html version; I'll try that. > "callable entity" is easily found in the index. Ah. I didn't think of that. > A "callable entity" is defined (in 6(2)) to be a subprogram or > entry. Thus an abstract subprogram is a callable entity even though > you can't really call it. Ok. > I don't see any prohibition on renaming an abstract subprogram. > However, renaming subprograms don't quite take on all the > characteristics of the subprograms they rename; see 8.5.4(12) for > instance. I suspect that has something to do with why renaming an > abstract subprogram could lead to an error, but I don't have time > right this minute to look into it further. > > -- Adam -- -- Stephe ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Renaming an abstract function 2001-11-17 3:08 ` Adam Beneschan 2001-11-17 17:47 ` Egil Harald Hoevik 2001-11-17 18:33 ` Stephen Leake @ 2001-11-17 22:00 ` Mark Biggar 2001-11-17 23:17 ` Nick Roberts 2001-11-19 15:38 ` Stephen Leake 2 siblings, 2 replies; 11+ messages in thread From: Mark Biggar @ 2001-11-17 22:00 UTC (permalink / raw) Adam Beneschan wrote: > > Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote in message news:<uvggau5ro.fsf@gsfc.nasa.gov>... > > "Nick Roberts" <nickroberts@adaos.worldonline.co.uk> writes: > > > > > When given the program: > > > > > > package Test1 is > > > type T is abstract tagged limited private; > > > function P (X, Y: in T) return T is abstract; > > > function "*" (A, B: in T) return T renames P; -- error line > > > private > > > type T is abstract tagged limited null record; > > > end; > > > > > > GNAT 3.12p on Windows 95 returns the error message: > > > > > > function that returns abstract type must be abstract > > > > > > Is this a bug in: (a) GNAT; (b) the RM95; or (c) my brain? > > > > Same error in gnat 3.14 (you should at least upgrade to 3.13p). > > > > RM 8.5.4 (2) says: > > > > 2. subprogram_renaming_declaration ::= > > subprogram_specification renames callable_entity_name; > > > > The term "callable_entity_name" is not mentioned elsewhere in the > > reference manual, which I find odd. > > Note that "callable_entity" is in italics, while "name" is not. In RM > notation, that means that the language expects the syntax of a "name" > (defined in 4.1), while "callable_entity" is a description that tells > you what the name has to represent. I guess if you're searching a > text file version of the RM, there's probably no indication that part > of it is in italics. "callable entity" is easily found in the index. > > A "callable entity" is defined (in 6(2)) to be a subprogram or entry. > Thus an abstract subprogram is a callable entity even though you can't > really call it. > > I don't see any prohibition on renaming an abstract subprogram. > However, renaming subprograms don't quite take on all the > characteristics of the subprograms they rename; see 8.5.4(12) for > instance. I suspect that has something to do with why renaming an > abstract subprogram could lead to an error, but I don't have time > right this minute to look into it further. There is an AI that addresses this problem: >!standard 8.5.4 (7) 00-07-12 >AI95-00211/06 >!class ramification 98-11-18 >!status Response 2000 00-01-24 >!status WG9 approved 99-06-12 >!status ARG Approved (with changes) 8-0-1 99-03-24 >!status work item 98-11-18 >!priority Medium >!difficulty Easy >!qualifier Clarification >!subject Can an abstract subprogram be renamed? > >!summary > >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. Thus, any renaming of an >inherited subprogram that must be overridden is illegal. This explains the compilation error as the renaming "*" is a must be overridden function as it has an abstract return type and thus is illegal. -- Mark Biggar mark.a.biggar@home.com ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Renaming an abstract function 2001-11-17 22:00 ` Mark Biggar @ 2001-11-17 23:17 ` Nick Roberts 2001-11-19 15:38 ` Stephen Leake 1 sibling, 0 replies; 11+ messages in thread From: Nick Roberts @ 2001-11-17 23:17 UTC (permalink / raw) "Mark Biggar" <mark.a.biggar@home.com> wrote in message news:3BF6DE1F.6C31A357@home.com... > ... > There is an AI that addresses this problem: [AI95-211] > ... > >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. Thus, any renaming of an > >inherited subprogram that must be overridden is illegal. Many thanks for pointing out this AI, Mark. > This explains the compilation error as the renaming "*" is a must be > overridden function as it has an abstract return type and thus is > illegal. I don't think the AI explains it at all, in fact. The renaming of "*" in my example is not attempting to rename an inherited subprogram. The type T is a root abstract type (not derived from anything), so the functions P and "*" are not inherited. -- Best wishes, Nick Roberts ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Renaming an abstract function 2001-11-17 22:00 ` Mark Biggar 2001-11-17 23:17 ` Nick Roberts @ 2001-11-19 15:38 ` Stephen Leake 2001-11-22 3:14 ` Nick Roberts 1 sibling, 1 reply; 11+ messages in thread From: Stephen Leake @ 2001-11-19 15:38 UTC (permalink / raw) Mark Biggar <mark.a.biggar@home.com> writes: > <snip example of renaming an abstract function returning an abstract > type> > > > package Test1 is > > > type T is abstract tagged limited private; > > > function P (X, Y: in T) return T is abstract; > > > function "*" (A, B: in T) return T renames P; -- error line > > > private > > > type T is abstract tagged limited null record; > > > end; > There is an AI that addresses this problem: > > >!standard 8.5.4 (7) 00-07-12 >AI95-00211/06 > >!class ramification 98-11-18 > >!status Response 2000 00-01-24 > >!status WG9 approved 99-06-12 > >!status ARG Approved (with changes) 8-0-1 99-03-24 > >!status work item 98-11-18 > >!priority Medium > >!difficulty Easy > >!qualifier Clarification > >!subject Can an abstract subprogram be renamed? > > > >!summary > > > >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. Thus, any renaming of an > >inherited subprogram that must be overridden is illegal. > > This explains the compilation error as the renaming "*" is a must be > overridden function as it has an abstract return type and thus is > illegal. > Well, the full text of the AI talks about renaming an _inherited_ subprogram, not the abstract subprogram itself. It does not discuss exactly what should happen for this case. Simply following the rules for inheriting abstract subprograms, you are required to give an overriding subprogram for any derived type. Thus, if the renaming is valid, you'd have to override both P and "*", which is surely not the intent. So it seems reasonable to conclude that the renaming itself is invalid. We could propose a "renaming inheritance" rule that says an equivalent renaming is applied to the overriding subprogram; that is the intent of this renaming. -- -- Stephe ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Renaming an abstract function 2001-11-19 15:38 ` Stephen Leake @ 2001-11-22 3:14 ` Nick Roberts 2001-11-23 15:40 ` Stephen Leake 0 siblings, 1 reply; 11+ messages in thread From: Nick Roberts @ 2001-11-22 3:14 UTC (permalink / raw) "Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message > ... > Well, the full text of the AI talks about renaming an _inherited_ > subprogram, not the abstract subprogram itself. It does not discuss > exactly what should happen for this case. Precisely my point (in parallel post). > Simply following the rules for inheriting abstract subprograms, you > are required to give an overriding subprogram for any derived type. > Thus, if the renaming is valid, you'd have to override both P and "*", This is correct. > which is surely not the intent. Yes it is the intent. The Rationale (8.3) makes this clear. > So it seems reasonable to conclude > that the renaming itself is invalid. No, I don't think so. > We could propose a "renaming inheritance" rule that says an equivalent > renaming is applied to the overriding subprogram; that is the intent > of this renaming. Intriguing idea, but it is already laid down: the renaming creates a new 'slot', thus both (the original and renamed) subprograms can be (and, in the case of an asbtract subprogram, would need to be) overridden separately. > > -- > -- Stephe -- Best wishes, Nick Roberts ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Renaming an abstract function 2001-11-22 3:14 ` Nick Roberts @ 2001-11-23 15:40 ` Stephen Leake 2001-11-24 3:55 ` Nick Roberts 0 siblings, 1 reply; 11+ messages in thread From: Stephen Leake @ 2001-11-23 15:40 UTC (permalink / raw) "Nick Roberts" <nickroberts@adaos.worldonline.co.uk> writes: > "Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message > > ... > > Well, the full text of the AI talks about renaming an _inherited_ > > subprogram, not the abstract subprogram itself. It does not discuss > > exactly what should happen for this case. > > Precisely my point (in parallel post). > > > Simply following the rules for inheriting abstract subprograms, you > > are required to give an overriding subprogram for any derived type. > > Thus, if the renaming is valid, you'd have to override both P and "*", > > This is correct. > > > which is surely not the intent. > > Yes it is the intent. The Rationale (8.3) makes this clear. Well, I meant the "intent of the programmer". If I rename a function, I "intend" to have two names for one function. If, when deriving the type, I must provide _two_ functions, that is not two names for _one_ function. Of course, I can provide the same function, but I'd prefer the language to enforce it. Rationale 8.3 does say the behavior of renamed primitive operations "may be considered surprising". I guess that's all I'm saying; I find the behavior of inherited renamed primitive operations surprising. But having read the Rationale (something I should do more often), I can see why it has to be this way. > > So it seems reasonable to conclude that the renaming itself is > > invalid. > > No, I don't think so. Right, this is pretty close to the example in the rationale. > > We could propose a "renaming inheritance" rule that says an > > equivalent renaming is applied to the overriding subprogram; that > > is the intent of this renaming. > > Intriguing idea, but it is already laid down: the renaming creates a new > 'slot', thus both (the original and renamed) subprograms can be (and, in the > case of an asbtract subprogram, would need to be) overridden separately. Yes, but the Rationale doesn't specifically address inheriting a renamed function. It would be good if it did. -- -- Stephe ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Renaming an abstract function 2001-11-23 15:40 ` Stephen Leake @ 2001-11-24 3:55 ` Nick Roberts 0 siblings, 0 replies; 11+ messages in thread From: Nick Roberts @ 2001-11-24 3:55 UTC (permalink / raw) "Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message news:uwv0hlcml.fsf@gsfc.nasa.gov... > ... Acknowledged, Nick ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2001-11-24 3:55 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-11-15 23:52 Renaming an abstract function Nick Roberts 2001-11-16 14:52 ` Stephen Leake 2001-11-17 3:08 ` Adam Beneschan 2001-11-17 17:47 ` Egil Harald Hoevik 2001-11-17 18:33 ` Stephen Leake 2001-11-17 22:00 ` Mark Biggar 2001-11-17 23:17 ` Nick Roberts 2001-11-19 15:38 ` Stephen Leake 2001-11-22 3:14 ` Nick Roberts 2001-11-23 15:40 ` Stephen Leake 2001-11-24 3:55 ` Nick Roberts
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox