* Re: Subprogram Renaming [not found] <md5:95D854EBD1A47E0E86027A3CC7DBD9A4> @ 1996-04-10 0:00 ` James A. Squire 1996-04-10 0:00 ` Robert A Duff 1996-04-10 0:00 ` Robert Dewar 1996-04-10 0:00 ` johndoe 1 sibling, 2 replies; 30+ messages in thread From: James A. Squire @ 1996-04-10 0:00 UTC (permalink / raw) On Wed, 10 Apr 1996 00:23:52 GMT, NETNEWS@AMERICAN.EDU wrote: > i'll answer: but i want to know how you're going to get me my $64,000... > > In article <316AEA8D.7600@csehp3.mdc.com> "James A. Squire" > <m193884@CSEHP3.MDC.COM> writes: > >Still (!) Nobody has answered the $64,000.00 question: WHY IS THIS SUCH > >A GOOD THING? In other words, why did they waste their time adding this > >ability to rename a subprogram body. > >Why should I do: >when I can do: > > > > >package q is >package q is > > procedure j; > procedure k; > >end q; >end q; > > > > >package body q is >package body q is > > procedure k; > procedure k is ... > > procedure j renames k; >end q; > >end q; > > well, there probably isn't a good reason for you to do what you have on the > left above. however, that is not exactly what was shown in the articles you > quoted. > > the point primarily addresses the case where "k" comes from a different > package. in that case, what you're saying is basically that the > "implementation" of "k" is exactly that of "j". why put lines in j that just > call k when the syntax is there (at least in ada95) to have any call to k > just be routed to j's code. 1. The example did not "with" in another package in which k would be found, so k had to be in package q. I just made that explicit. 2. Once again, the real question is: why do I need an explicit body for j when I can rename k in the spec of q? That has been my question all along. > 1) for certain operations, it may be desirable to use a rename > > take > package F is > subtype Unsigned_int is Interfaces.C.Unsigned_Int; > function "+"( Left, Right : Unsigned_Int ) return Unsigned_Int; > end F; > > then > package body F is > function "+"( Left, Right : Unsigned_Int ) return Unsigned_Int > renames Interfaces.C."+"; > end F; > > requires a "use F;" clause "use type F.Unsigned_Int"; in comparison not > having "+" in the spec requires a separate "use" for Interfaces.C; and > not using the renames requires a body for "+" that is basically extra > code. This example makes NO sense whatsoever to me. How about this instead: with Interfaces.C; package F is ... function "+" (Left, Right : Interfaces.C.Unsigned_Int) return Interfaces.C.Unsigned_Int renames Interfaces.C."+"; ... end F; > 2) in cases where you are attempting to create a package that only has > certain operations in the spec, you may find it desirable to completely > implement one of those operations by simply calling another. if the > subprogram parameter profile is identical, then using a renames saves > code. and you may not want all of the other functions to be visible > from the package where you got your renamed subprogram. in fact, they > may even be private. Finally, an answer that gives a real reason. Of course, if "they" are private, then "this" has to be a child package of "that". But in any event, the point is that you don't want a "with" clause in the "this"'s package spec. The "private" case, I can see. In fact, that's how you _have_ to do it. As for the other, I'm still thinking it over. > >Now that I KNOW I can do in Ada83. Since the parameter spec has to > >match exactly, I see no point to doing a rename in the body and hiding > >it from the user. All you are changing is the name it goes by. What's > >the point? > > well, depending on what you're referring to, your statement may actually be > wrong. and it brings up the case where the parameter profile is the same > but the look of the spec is different. take the following, which you can > presume to all be defined in the spec: > > procedure Create_Calculator_Button( > Button : in out Xt.Intrinsic.Widget; > Name : in Interfaces.C.Char_Array; > Label : in X.Strings.Const_Charp; > Foreground : access X.Xresource.XrmValue; > Background : access X.Xresource.XrmValue; > CBack : in Xt.Intrinsic.XtCallbackProc := Operation_Callback'ACCESS; > Width : in Xt.Intrinsic.XtArgVal := 38; > Height : in Xt.Intrinsic.XtArgVal := 30; > Button_Font_Charp : in X.Strings.Const_Charp := Normal_Font_Charp) > > procedure Create_Digit_Button( > Button : in out Xt.Intrinsic.Widget; > Name : in Interfaces.C.Char_Array; > Label : in X.Strings.Const_Charp; > Foreground : access X.Xresource.XrmValue := X.Colors.Yellow'ACCESS; > Background : access X.Xresource.XrmValue := X.Colors.Navy'ACCESS; > CBack : in Xt.Intrinsic.XtCallbackProc := Input_Digit_callback'Access; > Width : in Xt.Intrinsic.XtArgVal := 38; > Height : in Xt.Intrinsic.XtArgVal := 30; > Button_Font_Charp : in X.Strings.Const_Charp := Big_Font_Charp ) > renames Create_Calculator_Button; > > procedure Create_Operator_Button( > Button : in out Xt.Intrinsic.Widget; > Name : in Interfaces.C.Char_Array; > Label : in X.Strings.Const_Charp; > Foreground : access X.Xresource.XrmValue := X.Colors.White'ACCESS; > Background : access X.Xresource.XrmValue := X.Colors.SteelBlue'ACCESS; > CBack : in Xt.Intrinsic.XtCallbackProc := Operation_callback'Access; > Width : in Xt.Intrinsic.XtArgVal := 38; > Height : in Xt.Intrinsic.XtArgVal := 30; > Button_Font_Charp : in X.Strings.Const_Charp := Big_Font_Charp ) > renames Create_Calculator_Button; > > now, the code for the above is basically all the same. but, since the last > two definitions have all those extra foreground and background defaults, and > since the Button_Font_Charp has changed for them from the original, it allows > much more terse call-site naming, while maintaining some uniformity amongst > buttons of the same ilk: Are you saying that the above is legal in Ada95? So defaults can be different? (I'm sure this is illegal in Ada83) ------------------------------ On Wed, 10 Apr 1996 00:51:06 GMT, Robert A Duff <bobduff@WORLD.STD.COM> wrote: > It's not SUCH A GOOD THING IN ALL CAPS. It's just a minor short-hand. > No big deal. You seem to be expecting some AMAZING NEW CAPABILITY -- > but all you get is a shorthand notation. I never said nor implied that I was expecting some AMAZING NEW CAPABILITY. I was, however, expecting something more than a shorthand. Shorthands do not seem to me to be worthy of attention when upgrading a language. There should be something more to it than that. [my example snipped] > Well, what if K were in another package, and you want the implementation > of J to just call K? In Ada 83, you have to write "procedure j(...) is > begin k(...); end j;", whereas in Ada 95 you can write "procedure j( > renames K;". Nobody is saying this is some amazing wonderfulness. It's > just a shorthand notation that seems nice in some situations. And that was what I was asking: _What_ situations??? As mentioned before, in Ada83 I would just write "procedure j(...) renames Other_Package.k;" in the spec. > >> As Robert Dewar said, this has nothing to do with syntax rules -- the > >> syntax for renamings is the same. The difference is where they're > >> allowed, and what they mean. To find the rules, you have to look at the > >> text under subprogram renamings (as opposed to just looking at the BNF > >> syntax rules). > > > >I read those - 8.5.4 and 6.3.1. What does "subtype of the profile" > >mean? > > I guess you're referring to 6.3.1(17). It just mean the subtypes of the > parameters of whatever subprogram you're talking about. If you want to > use renaming-as-body, you have to have matching parameter subtypes. > This rule is stricter than the "normal" (Ada 83) renaming rules for > renaming-as-declaration. Oh, wait a minute. "Type conformance" refers to the base types then? Then, "Subtype conformance" refers to the actual parameter types being used? If that's not it, then I must say I am _really_ confused. If that _is_ it, then as far as I can tell, that describes perfectly what renaming requires in Ada83, so I must disagree with your last statement. -- James Squire MDA Avionics Tools & Processes ja_squire@csehp3.mdc.com "one of these days I'm going to better myself by going to Knight school" "You'll be a web knight instead of a web page!" ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Subprogram Renaming 1996-04-10 0:00 ` Subprogram Renaming James A. Squire @ 1996-04-10 0:00 ` Robert A Duff 1996-04-11 0:00 ` Adam Beneschan 1996-04-10 0:00 ` Robert Dewar 1 sibling, 1 reply; 30+ messages in thread From: Robert A Duff @ 1996-04-10 0:00 UTC (permalink / raw) In article <316BC3D6.14E7@csehp3.mdc.com>, James A. Squire <m193884@CSEHP3.MDC.COM> wrote: >On Wed, 10 Apr 1996 00:23:52 GMT, NETNEWS@AMERICAN.EDU wrote: > >> i'll answer: but i want to know how you're going to get me my $64,000... Yes, I would like $64,000, too. Please. ;-) >2. Once again, the real question is: why do I need an explicit body >for j when I can rename k in the spec of q? That has been my question >all along. OK, I finally understand your question. The answer is that you might not want to put this information in the spec. A possible reason is: If you put it in the spec, then re-compilation costs are sometimes *much* higher. So you want to declare j in the spec, but implement it in the body to avoid those recompilation costs. You could, of course, write a body for j that just calls k. The ability to use a renaming as body is just a short-hand for that kind of call-through body. Another possible reason is that the spec where k is declared already 'with'es the spec where j is declared, so you can't put the renaming "j renames k" in the spec because that would cause a circular dependence, which is illegal. Another possible reason: You want the spec to be the same, but you have different bodies, depending on the target system. In one case, the body of j is just a renaming, but in another case, it does more. >> 1) for certain operations, it may be desirable to use a rename >> >> take >> package F is >> subtype Unsigned_int is Interfaces.C.Unsigned_Int; >> function "+"( Left, Right : Unsigned_Int ) return Unsigned_Int; >> end F; >> >> then >> package body F is >> function "+"( Left, Right : Unsigned_Int ) return Unsigned_Int >> renames Interfaces.C."+"; >> end F; >> >> requires a "use F;" clause "use type F.Unsigned_Int"; in comparison not >> having "+" in the spec requires a separate "use" for Interfaces.C; and >> not using the renames requires a body for "+" that is basically extra >> code. > >This example makes NO sense whatsoever to me. How about this instead: > >with Interfaces.C; >package F is > ... > function "+" (Left, Right : Interfaces.C.Unsigned_Int) return > Interfaces.C.Unsigned_Int renames Interfaces.C."+"; > ... >end F; Yes, that works fine. But it means the spec of package F depends on Interfaces.C. Now, of course, Interfaces.C isn't likely to change anytime soon, since it's defined in the RM. But if, instead, this was a user-defined package, then it very well might change, and you very well might want to avoid depending on it from a package spec. >Are you saying that the above is legal in Ada95? So defaults can be >different? (I'm sure this is illegal in Ada83) It is legal, in both Ada 83 and Ada 95, for a renaming to change the defaults. >I never said nor implied that I was expecting some AMAZING NEW >CAPABILITY. I was, however, expecting something more than a shorthand. >Shorthands do not seem to me to be worthy of attention when upgrading a >language. There should be something more to it than that. Sorry to disappoint you, but it really is just a short-hand. In every case where a renaming-as-body is used, you could just as well write a plain old body. The only advantage is that the renaming-as-body is 1 line of code, whereas the plain old body is 4 lines of code -- the verbosity in this case damages readability. Not a big deal. The renaming as body *might* be more efficient, but that's questionable. In GNAT, I believe that a renaming as body and the plain old body will generate identical code. >And that was what I was asking: _What_ situations??? As mentioned >before, in Ada83 I would just write "procedure j(...) renames >Other_Package.k;" in the spec. I hope my answer above is sufficient -- to avoid depending on a spec from a spec, which can cause *huge* recompilation costs in some cases. >Oh, wait a minute. "Type conformance" refers to the base types then? >Then, "Subtype conformance" refers to the actual parameter types being >used? If that's not it, then I must say I am _really_ confused. If >that _is_ it, then as far as I can tell, that describes perfectly what >renaming requires in Ada83, so I must disagree with your last statement. Not sure what you're asking. Type conformance refers to types of parameters, subtype conformance refers to subtypes of parameters. Type conformance is less strict that subtype conformance -- that is, if X and Y are subtype conformant, then they are also type conformant, but not the other way around. You seem to misunderstand the rules for renaming in Ada 83. Subtype conformance is *not* required -- you can declare different subtypes, but they are *ignored*. This is, admittedly, a bit odd. For a renaming-as-declaration (which is the old Ada 83 kind), mode conformance is required, which is less strict than subtype conformance. For a renaming-as-body, subtype conformance is required. Read RM95-8.5.4. - Bob ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Subprogram Renaming 1996-04-10 0:00 ` Robert A Duff @ 1996-04-11 0:00 ` Adam Beneschan 1996-04-11 0:00 ` Robert Dewar 1996-04-11 0:00 ` Robert A Duff 0 siblings, 2 replies; 30+ messages in thread From: Adam Beneschan @ 1996-04-11 0:00 UTC (permalink / raw) bobduff@world.std.com (Robert A Duff) writes: >>I never said nor implied that I was expecting some AMAZING NEW >>CAPABILITY. I was, however, expecting something more than a shorthand. >>Shorthands do not seem to me to be worthy of attention when upgrading a >>language. There should be something more to it than that. > >Sorry to disappoint you, but it really is just a short-hand. In every >case where a renaming-as-body is used, you could just as well write a >plain old body. The only advantage is that the renaming-as-body is 1 >line of code, whereas the plain old body is 4 lines of code -- the >verbosity in this case damages readability. Not a big deal. The >renaming as body *might* be more efficient, but that's questionable. In >GNAT, I believe that a renaming as body and the plain old body will >generate identical code. Just out of curiosity: package q is procedure j; end q; package body q is procedure k; procedure j renames k; end q; Are j'address and k'address equal? Is there anything in the RM that says one way or the other whether they must be equal? How about j'access and k'access? I can't think of a legitimate reason to compare the two in actual code, in either case. I'm just curious if the RM says anything about it, and if this would prevent the compiler from generating code for "j" that calls "k". -- Adam ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Subprogram Renaming 1996-04-11 0:00 ` Adam Beneschan @ 1996-04-11 0:00 ` Robert Dewar 1996-04-11 0:00 ` Robert A Duff 1 sibling, 0 replies; 30+ messages in thread From: Robert Dewar @ 1996-04-11 0:00 UTC (permalink / raw) Adam says "Just out of curiosity: package q is procedure j; end q; package body q is procedure k; procedure j renames k; end q; Are j'address and k'address equal? Is there anything in the RM that says one way or the other whether they must be equal?" The RM has nothing to say on this! ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Subprogram Renaming 1996-04-11 0:00 ` Adam Beneschan 1996-04-11 0:00 ` Robert Dewar @ 1996-04-11 0:00 ` Robert A Duff 1 sibling, 0 replies; 30+ messages in thread From: Robert A Duff @ 1996-04-11 0:00 UTC (permalink / raw) In article <4kjkg6$4m2@krusty.irvine.com>, Adam Beneschan <adam@irvine.com> wrote: > package q is > procedure j; > end q; > > package body q is > procedure k; > procedure j renames k; > end q; > >Are j'address and k'address equal? Is there anything in the RM that >says one way or the other whether they must be equal? No. The RM does not require them to be equal, nor does it require them to be unequal. >How about j'access and k'access? No, no requirement. In fact, it's worse than that -- the RM does not even require that P'Access = P'Access, for any procedure P. See 4.5.2(13-13.a) and 3.10.2(39). >I can't think of a legitimate reason to compare the two in actual >code, in either case. I'm just curious if the RM says anything about >it, and if this would prevent the compiler from generating code for >"j" that calls "k". The compiler can generate code for j that calls k. It can also generate code for j that just *jumps* to the start of k (so the return instruction in k returns directly to the caller of j). Or, it can generate no code for j, and make calls to j and k call to the same address. - Bob ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Subprogram Renaming 1996-04-10 0:00 ` Subprogram Renaming James A. Squire 1996-04-10 0:00 ` Robert A Duff @ 1996-04-10 0:00 ` Robert Dewar 1996-04-11 0:00 ` Jonas Nygren 1 sibling, 1 reply; 30+ messages in thread From: Robert Dewar @ 1996-04-10 0:00 UTC (permalink / raw) James Squire asks "2. Once again, the real question is: why do I need an explicit body for j when I can rename k in the spec of q? That has been my question all along." That's very easy to answer (and to my reading has been answerd several times already in this thread). YOu put something in the spec if it is part of the specification. One can imagine cases where it is part of the spec that A renames B, as for example when you deliberately have two names for the identical same operation. But if the renaming is essentailly just a choice of how a particular function is implemented then it is a serious violation of the abstraction to expose the renaming. For example, it a package providing set abstractions, I would not like to see: Is_Member (E : Element; S : Set) return Boolean renames Binary_Tree_Ops.Test_Item_Present; since it is none of my business that at the moment sets are implemented using the binary tree package. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Subprogram Renaming 1996-04-10 0:00 ` Robert Dewar @ 1996-04-11 0:00 ` Jonas Nygren 1996-04-11 0:00 ` Robert Dewar 0 siblings, 1 reply; 30+ messages in thread From: Jonas Nygren @ 1996-04-11 0:00 UTC (permalink / raw) Robert Dewar wrote: > > > YOu put something in the spec if it is part of the specification. One visible part of the ^^ > can imagine cases where it is part of the spec that A renames B, as for > example when you deliberately have two names for the identical same > operation. > > But if the renaming is essentailly just a choice of how a particular > function is implemented then it is a serious violation of the abstraction > to expose the renaming. But it could be put in the private part, without 'exposing the renaming'. Robert mentioned before that this had a performance drawback but I can't see that this would be the case if you have a generic package. I also believe I saw something along the lines that if the renaming is put in the package body this limits the possibilities to further override the sub- program. This could be a motive to put the renaming in the spec part. ------------------------------------------------------- -- Jonas Nygren -- ehsjony@ehs.ericsson.se ------------------------------------------------------- ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Subprogram Renaming 1996-04-11 0:00 ` Jonas Nygren @ 1996-04-11 0:00 ` Robert Dewar 1996-04-12 0:00 ` Jonas Nygren 0 siblings, 1 reply; 30+ messages in thread From: Robert Dewar @ 1996-04-11 0:00 UTC (permalink / raw) Jonas asked: "But it could be put in the private part, without 'exposing the renaming'. Robert mentioned before that this had a performance drawback but I can't see that this would be the case if you have a generic package." No, the performance penalty of creating a body occurs only if the renaming is in the body. Actually, as Bob Duff pointed out, not all compilers will take advantage of the possible performance gain (equiavlent to automatic inlining) that completion-with-renaming can provide (GNAT does not, since it requires renaming capability at the linker level, a feature that not all linkers provide). However, this performance penalty can in any case be completely eliminated by use of pragma Inline so in the case where the renaming-as-body appears in the body it is a shorthand and nothing more. In the private part it is a different feature, but I don't understand Jonas' comment above. Sure in Ada 83 you could put a renaming in the private part, and it wouldn't expose the renaming -- it also would not expose ANYTHING and could not be used by a client of the package and therefore would be completely useless! The ability to use renaming-as-body in the private part is a new Ada 95 feature which is quite useful, sometimes it can completely eliminate a package body that would otherwise be required in Ada 83. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Subprogram Renaming 1996-04-11 0:00 ` Robert Dewar @ 1996-04-12 0:00 ` Jonas Nygren 0 siblings, 0 replies; 30+ messages in thread From: Jonas Nygren @ 1996-04-12 0:00 UTC (permalink / raw) Robert Dewar wrote: > > Jonas asked: > > "But it could be put in the private part, without 'exposing the renaming'. > Robert mentioned before that this had a performance drawback but I can't see > that this would be the case if you have a generic package." > > No, the performance penalty of creating a body occurs only if the renaming > is in the body. Actually, as Bob Duff pointed out, not all compilers > will take advantage of the possible performance gain (equiavlent to > automatic inlining) that completion-with-renaming can provide (GNAT does > not, since it requires renaming capability at the linker level, a feature > that not all linkers provide). However, this performance penalty can in > any case be completely eliminated by use of pragma Inline so in the case > where the renaming-as-body appears in the body it is a shorthand and > nothing more. > > In the private part it is a different feature, but I don't understand > Jonas' comment above. Sure in Ada 83 you could put a renaming in the > private part, and it wouldn't expose the renaming -- it also would not > expose ANYTHING and could not be used by a client of the package and > therefore would be completely useless! Well, I don't know anything about Ada 83 and just a little bit more about Ada 95 :-) > > The ability to use renaming-as-body in the private part is a new Ada 95 > feature which is quite useful, sometimes it can completely eliminate a > package body that would otherwise be required in Ada 83. Sorry, I perhaps misunderstood youre earlier posting. I read this as you were advocating that all renaming should be in the body and then I tried to point out that there could be reasons for doing the renaming in the private part of the spec. My motivation for this was perhaps not the best. ------------------------------------------------------- -- Jonas Nygren -- ehsjony@ehs.ericsson.se ------------------------------------------------------- ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Subprogram Renaming [not found] <md5:95D854EBD1A47E0E86027A3CC7DBD9A4> 1996-04-10 0:00 ` Subprogram Renaming James A. Squire @ 1996-04-10 0:00 ` johndoe 1 sibling, 0 replies; 30+ messages in thread From: johndoe @ 1996-04-10 0:00 UTC (permalink / raw) In article <316BC3D6.14E7@csehp3.mdc.com> "James A. Squire" <m193884@CSEHP3.MDC.COM> writes: > >Newsgroups: comp.lang.ada >Date: Wed, 10 Apr 1996 09:21:10 -0500 > >Are you saying that the above is legal in Ada95? So defaults can be >different? (I'm sure this is illegal in Ada83) the examples were taken directly from a program developed using ada95. and the original idea came from programs written in ada83 using the same idea. having procedures rename other procedures with different default values is not illegal in ada83. --johndoe ^ permalink raw reply [flat|nested] 30+ messages in thread
[parent not found: <md5:3CC2294B6049DDBD8790280EABCEDE81>]
* Re: Subprogram Renaming [not found] <md5:3CC2294B6049DDBD8790280EABCEDE81> @ 1996-04-12 0:00 ` James A. Squire 0 siblings, 0 replies; 30+ messages in thread From: James A. Squire @ 1996-04-12 0:00 UTC (permalink / raw) On Wed, 10 Apr 1996 23:42:36 GMT, Robert A Duff <bobduff@WORLD.STD.COM> wrote: > In article <316BC3D6.14E7@csehp3.mdc.com>, > James A. Squire <m193884@CSEHP3.MDC.COM> wrote: > >Oh, wait a minute. "Type conformance" refers to the base types then? > >Then, "Subtype conformance" refers to the actual parameter types being > >used? If that's not it, then I must say I am _really_ confused. If > >that _is_ it, then as far as I can tell, that describes perfectly what > >renaming requires in Ada83, so I must disagree with your last statement. > > Not sure what you're asking. Type conformance refers to types of > parameters, subtype conformance refers to subtypes of parameters. When you say subtype and then later type, I don't know which one refers to the text that I see between the "[in] [out]" and the ";". That's what I'm asking. I assume that this text in between the mode field and the ";" is considered the subtype, right? Therefore, subtype conformance means that the actual type names explicitly used in the profiles must be exactly the same, right? Then type conformance simply means that the base types that these subtypes were derived from must be the same, right? > Type conformance is less strict that subtype conformance -- that is, if X and > Y are subtype conformant, then they are also type conformant, but not > the other way around. That's the _only_ thing that _was_ clear from the LRM. -- James Squire MDA Avionics Tools & Processes ja_squire@csehp3.mdc.com "one of these days I'm going to better myself by going to Knight school" "You'll be a web knight instead of a web page!" ^ permalink raw reply [flat|nested] 30+ messages in thread
[parent not found: <md5:87494FB95037B9578F62831DE10B6BB3>]
* Re: Subprogram Renaming [not found] <md5:87494FB95037B9578F62831DE10B6BB3> @ 1996-04-10 0:00 ` James A. Squire 0 siblings, 0 replies; 30+ messages in thread From: James A. Squire @ 1996-04-10 0:00 UTC (permalink / raw) On Mon, 8 Apr 1996 22:12:23, Robert Dewar <dewar@CS.NYU.EDU> wrote: > James Squire said > > "And my question was, why does being able to rename a subprogram AS A > BODY matter? What is so NEW about this? Why should I care about this > NEW thing?" > > Well any new feature may or may not be useful to you, but please study > my example more carefully, you CANNOT do whyat I suggested in Ada 83. I _knew that_ from the beginning. _That_ was _never_ my question. > The new feature is, as shown in my example, the ability to provide a > completion using a renaming, instead of a normal body. This saves having > to write a junk wrapper routine with an extra call. I _knew_ what the new feature _was_ all along. > It is most useful when used in the private part of a spec. How come you never mentioned the word "private" in your example? That would have at least meant something to me. ------------------------------ On Tue, 9 Apr 1996 20:52:04, Robert Dewar <dewar@CS.NYU.EDU> wrote: > James Squire said: > > "Still (!) Nobody has answered the $64,000.00 question: WHY IS THIS SUCH > A GOOD THING? In other words, why did they waste their time adding this > ability to rename a subprogram body. Why should I do:" > > <deleted example> > > If you think this then please answer the following question: > > why do we provide subprogram renaming at all? It is after all redundant, > you could always provide a junk body? Don't get me started. I _only_ use renames to avoid using the "use" clause, and then _only_ for operators. As far as I am concerned, it is a flaw in the Ada83 language that operators are not, in this instance, treated (as they are in every other language I am aware of) as part of the language itself - i.e., why should I ever have to do _anything_ to make implicit operators (declared by the compiler, not me) visible? However, I think I understand some of the benefits of this flaw, and as this constitutes topic drift, I'll just say that I trust they made the right decision. > There is no question that this is a useful new capability, especially, > as I noted before, when the renaming as body is not in the package body, > but instead in the private part of the package spec. I can see it being useful when the subprogram being renamed as a body is itself in the private part of another package, but what's the difference between putting the renaming statement in the private part of the spec and putting it in the body? > This is obviously better than putting a renaming in the visible part of > the spec, as Gary quite clearly explained. Gary who? I don't remember anyone named Gary responding to my question. It is possible that I never received it since I am reading this newsgroup through the INFO-ADA mailing list. -- James Squire MDA Avionics Tools & Processes ja_squire@csehp3.mdc.com "one of these days I'm going to better myself by going to Knight school" "You'll be a web knight instead of a web page!" ^ permalink raw reply [flat|nested] 30+ messages in thread
[parent not found: <md5:88A5E8822105A2023A0A951BB5EC646E>]
* Re: Subprogram Renaming [not found] <md5:88A5E8822105A2023A0A951BB5EC646E> @ 1996-04-10 0:00 ` James A. Squire 0 siblings, 0 replies; 30+ messages in thread From: James A. Squire @ 1996-04-10 0:00 UTC (permalink / raw) On Tue, 9 Apr 1996 10:22:47, Gary McKee <gmckee@CLOUDNINE.COM> wrote: > The rationale given when this change was submitted to the requirements team > was as follows: > > The avowed purpose of a package specification is to offer a 'contract' for > delivery of software services as implemented by the package body. When a > subprogram is implemented via a renaming of another subprogram (procedure j > renames k;), the 'contract' is compromised because the implementation must > be placed in the specification. This is contrary to the paradigms of > 'modularity, abstraction, and information hiding'. OK. I can see in some cases where this 'contract' is actually useful. Of course, the only implementation that is being put into the spec is the actual name and location of the implementation. Every thing else is interface details which are supposed to be public. Frankly, I've seen worse cases than subprogram specs as far as breaking modularity, abstraction, and information hiding, which are allowed by both Ada83 and Ada95, such as defining a variable (already a no-no in my book) by renaming a function call. What I see is that if you rename a subprogram from another package in your package spec, then you have to with in the other package in the spec, which means that potentially the other package spec can have an affect on the user of your package, which you may not want. Of course, if you really don't want the user to pay any attention to the other package, you should make the other package a private child of your package, at which point Ada95 requires you to rename your public subprogram as the body of a subprogram in that private child. -- James Squire MDA Avionics Tools & Processes ja_squire@csehp3.mdc.com "one of these days I'm going to better myself by going to Knight school" "You'll be a web knight instead of a web page!" ^ permalink raw reply [flat|nested] 30+ messages in thread
[parent not found: <md5:FE4AB546A8392541EDC1E3FE12E3D8AF>]
* Re: Subprogram Renaming [not found] <md5:FE4AB546A8392541EDC1E3FE12E3D8AF> @ 1996-04-09 0:00 ` James A. Squire 1996-04-09 0:00 ` Robert Dewar ` (2 more replies) 1996-04-10 0:00 ` johndoe 1 sibling, 3 replies; 30+ messages in thread From: James A. Squire @ 1996-04-09 0:00 UTC (permalink / raw) Robert A Duff <bobduff@WORLD.STD.COM> wrote: > In article <316951C3.CE4@csehp3.mdc.com>, > James A. Squire <m193884@CSEHP3.MDC.COM> wrote: > >> package q is > >> procedure j; > >> end q; > >> > >> package body q is > >> ... > >> procedure j renames k; > > > >which looks like a rename of a spec to me. I can do this in Ada83. > > No, the above is illegal in Ada 83. In Ada 83, you have two > declarations of J, which are homographs, and therefore illegal. And you > have a missing body for the first J, which is also illegal. The new You are right about that. That comment was my mistake. However (!!!)... > thing in Ada 95 is that the renaming can act as the body of the first J. > This is no big deal -- the renaming is just a short-hand notation for > "procedure j is begin k; end;". But it was illegal in Ada 83. Still (!) Nobody has answered the $64,000.00 question: WHY IS THIS SUCH A GOOD THING? In other words, why did they waste their time adding this ability to rename a subprogram body. Why should I do: package q is procedure j; end q; package body q is procedure k; procedure j renames k; end q; when I can do: package q is procedure k; end q; package body q is procedure k is ... end q; Now that I KNOW I can do in Ada83. Since the parameter spec has to match exactly, I see no point to doing a rename in the body and hiding it from the user. All you are changing is the name it goes by. What's the point? > As Robert Dewar said, this has nothing to do with syntax rules -- the > syntax for renamings is the same. The difference is where they're > allowed, and what they mean. To find the rules, you have to look at the > text under subprogram renamings (as opposed to just looking at the BNF > syntax rules). I read those - 8.5.4 and 6.3.1. What does "subtype of the profile" mean? -- James Squire MDA Avionics Tools & Processes ja_squire@csehp3.mdc.com "one of these days I'm going to better myself by going to Knight school" "You'll be a web knight instead of a web page!" ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Subprogram Renaming 1996-04-09 0:00 ` James A. Squire @ 1996-04-09 0:00 ` Robert Dewar 1996-04-10 0:00 ` Robert A Duff 1996-04-11 0:00 ` Mark A Biggar 2 siblings, 0 replies; 30+ messages in thread From: Robert Dewar @ 1996-04-09 0:00 UTC (permalink / raw) James Squire said: "Still (!) Nobody has answered the $64,000.00 question: WHY IS THIS SUCH A GOOD THING? In other words, why did they waste their time adding this ability to rename a subprogram body. Why should I do:" <deleted example> If you think this then please answer the following question: why do we provide subprogram renaming at all? It is after all redundant, you could always provide a junk body? There is no question that this is a useful new capability, especially, as I noted before, when the renaming as body is not in the package body, but instead in the private part of the package spec. This is obviously better than putting a renaming in the visible part of the spec, as Gary quite clearly explained. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Subprogram Renaming 1996-04-09 0:00 ` James A. Squire 1996-04-09 0:00 ` Robert Dewar @ 1996-04-10 0:00 ` Robert A Duff 1996-04-11 0:00 ` Mark A Biggar 2 siblings, 0 replies; 30+ messages in thread From: Robert A Duff @ 1996-04-10 0:00 UTC (permalink / raw) In article <316AEA8D.7600@csehp3.mdc.com>, James A. Squire <m193884@CSEHP3.MDC.COM> wrote: >Still (!) Nobody has answered the $64,000.00 question: WHY IS THIS SUCH >A GOOD THING? It's not SUCH A GOOD THING IN ALL CAPS. It's just a minor short-hand. No big deal. You seem to be expecting some AMAZING NEW CAPABILITY -- but all you get is a shorthand notation. >... In other words, why did they waste their time adding this >ability to rename a subprogram body. Why should I do: > >package q is > procedure j; >end q; > >package body q is > procedure k; > procedure j renames k; >end q; > >when I can do: > >package q is > procedure k; >end q; > >package body q is > procedure k is ... >end q; Well, what if K were in another package, and you want the implementation of J to just call K? In Ada 83, you have to write "procedure j(...) is begin k(...); end j;", whereas in Ada 95 you can write "procedure j( renames K;". Nobody is saying this is some amazing wonderfulness. It's just a shorthand notation that seems nice in some situations. >Now that I KNOW I can do in Ada83. Since the parameter spec has to >match exactly, I see no point to doing a rename in the body and hiding >it from the user. All you are changing is the name it goes by. What's >the point? The point is layering one abstraction on top of another, where *some* subprograms don't actually do anything, except pass the buck to another lower-level subprogram. Usually the *other* subprogram is in another package -- unlike your example, which renames a subprogram from the *same* package, which, as you noted, is rather silly. >> As Robert Dewar said, this has nothing to do with syntax rules -- the >> syntax for renamings is the same. The difference is where they're >> allowed, and what they mean. To find the rules, you have to look at the >> text under subprogram renamings (as opposed to just looking at the BNF >> syntax rules). > >I read those - 8.5.4 and 6.3.1. What does "subtype of the profile" >mean? I guess you're referring to 6.3.1(17). It just mean the subtypes of the parameters of whatever subprogram you're talking about. If you want to use renaming-as-body, you have to have matching parameter subtypes. This rule is stricter than the "normal" (Ada 83) renaming rules for renaming-as-declaration. - Bob P.S. I don't blame you for being confused. These rules are written in a rather language-lawyerly fashion. :-( ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Subprogram Renaming 1996-04-09 0:00 ` James A. Squire 1996-04-09 0:00 ` Robert Dewar 1996-04-10 0:00 ` Robert A Duff @ 1996-04-11 0:00 ` Mark A Biggar 2 siblings, 0 replies; 30+ messages in thread From: Mark A Biggar @ 1996-04-11 0:00 UTC (permalink / raw) In article <316AEA8D.7600@csehp3.mdc.com> "James A. Squire" <m193884@CSEHP3.MDC.COM> writes: >Still (!) Nobody has answered the $64,000.00 question: WHY IS THIS SUCH >A GOOD THING? In other words, why did they waste their time adding this >ability to rename a subprogram body. Why should I do: >package q is > procedure j; >end q; >package body q is > procedure k; > procedure j renames k; >end q; >when I can do: >package q is > procedure k; >end q; >package body q is > procedure k is ... >end q; >Now that I KNOW I can do in Ada83. Since the parameter spec has to >match exactly, I see no point to doing a rename in the body and hiding >it from the user. All you are changing is the name it goes by. What's >the point? Actaully the important case to look at is the following: package q is procedure j; end q; with t; package body q is procedure j renames t.k; end q; This allows the reexport of a procedure defined elsewhere with out requiring a possible error introducing wrapper procedure. -- Mark Biggar mab@wdl.loral.com ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Subprogram Renaming [not found] <md5:FE4AB546A8392541EDC1E3FE12E3D8AF> 1996-04-09 0:00 ` James A. Squire @ 1996-04-10 0:00 ` johndoe 1996-04-10 0:00 ` Norman H. Cohen 1 sibling, 1 reply; 30+ messages in thread From: johndoe @ 1996-04-10 0:00 UTC (permalink / raw) i'll answer: but i want to know how you're going to get me my $64,000... In article <316AEA8D.7600@csehp3.mdc.com> "James A. Squire" <m193884@CSEHP3.MDC.COM> writes: >Still (!) Nobody has answered the $64,000.00 question: WHY IS THIS SUCH >A GOOD THING? In other words, why did they waste their time adding this >ability to rename a subprogram body. >Why should I do: >when I can do: > > >package q is >package q is > procedure j; > procedure k; >end q; >end q; > > >package body q is >package body q is > procedure k; > procedure k is ... > procedure j renames k; >end q; >end q; well, there probably isn't a good reason for you to do what you have on the left above. however, that is not exactly what was shown in the articles you quoted. the point primarily addresses the case where "k" comes from a different package. in that case, what you're saying is basically that the "implementation" of "k" is exactly that of "j". why put lines in j that just call k when the syntax is there (at least in ada95) to have any call to k just be routed to j's code. 1) for certain operations, it may be desirable to use a rename take package F is subtype Unsigned_int is Interfaces.C.Unsigned_Int; function "+"( Left, Right : Unsigned_Int ) return Unsigned_Int; end F; then package body F is function "+"( Left, Right : Unsigned_Int ) return Unsigned_Int renames Interfaces.C."+"; end F; requires a "use F;" clause "use type F.Unsigned_Int"; in comparison not having "+" in the spec requires a separate "use" for Interfaces.C; and not using the renames requires a body for "+" that is basically extra code. 2) in cases where you are attempting to create a package that only has certain operations in the spec, you may find it desirable to completely implement one of those operations by simply calling another. if the subprogram parameter profile is identical, then using a renames saves code. and you may not want all of the other functions to be visible from the package where you got your renamed subprogram. in fact, they may even be private. private package A.Z is procedure M( X : Integer; Y : Boolean ); procedure N( X : Integer ); end A.Z; package A.Y is procedure Only_Visible( P : Integer; Q : Boolean ); end A.Y; with A.Z.M; package body A.Y is procedure Only_Visible( P : Integer; Q : Boolean ) renames A.Z.M; end A.Y; in the above case, no one outside of the hierarchy of A is allowed to with A.Z . but, since A.Z.M is exactly the same as A.Y.Only_Visible, why duplicate effort. >Now that I KNOW I can do in Ada83. Since the parameter spec has to >match exactly, I see no point to doing a rename in the body and hiding >it from the user. All you are changing is the name it goes by. What's >the point? well, depending on what you're referring to, your statement may actually be wrong. and it brings up the case where the parameter profile is the same but the look of the spec is different. take the following, which you can presume to all be defined in the spec: procedure Create_Calculator_Button( Button : in out Xt.Intrinsic.Widget; Name : in Interfaces.C.Char_Array; Label : in X.Strings.Const_Charp; Foreground : access X.Xresource.XrmValue; Background : access X.Xresource.XrmValue; CBack : in Xt.Intrinsic.XtCallbackProc := Operation_Callback'ACCESS; Width : in Xt.Intrinsic.XtArgVal := 38; Height : in Xt.Intrinsic.XtArgVal := 30; Button_Font_Charp : in X.Strings.Const_Charp := Normal_Font_Charp) procedure Create_Digit_Button( Button : in out Xt.Intrinsic.Widget; Name : in Interfaces.C.Char_Array; Label : in X.Strings.Const_Charp; Foreground : access X.Xresource.XrmValue := X.Colors.Yellow'ACCESS; Background : access X.Xresource.XrmValue := X.Colors.Navy'ACCESS; CBack : in Xt.Intrinsic.XtCallbackProc := Input_Digit_callback'Access; Width : in Xt.Intrinsic.XtArgVal := 38; Height : in Xt.Intrinsic.XtArgVal := 30; Button_Font_Charp : in X.Strings.Const_Charp := Big_Font_Charp ) renames Create_Calculator_Button; procedure Create_Operator_Button( Button : in out Xt.Intrinsic.Widget; Name : in Interfaces.C.Char_Array; Label : in X.Strings.Const_Charp; Foreground : access X.Xresource.XrmValue := X.Colors.White'ACCESS; Background : access X.Xresource.XrmValue := X.Colors.SteelBlue'ACCESS; CBack : in Xt.Intrinsic.XtCallbackProc := Operation_callback'Access; Width : in Xt.Intrinsic.XtArgVal := 38; Height : in Xt.Intrinsic.XtArgVal := 30; Button_Font_Charp : in X.Strings.Const_Charp := Big_Font_Charp ) renames Create_Calculator_Button; now, the code for the above is basically all the same. but, since the last two definitions have all those extra foreground and background defaults, and since the Button_Font_Charp has changed for them from the original, it allows much more terse call-site naming, while maintaining some uniformity amongst buttons of the same ilk: Create_Operator_Button( Buttons(PLUS), "operatorPlus", Plus_charp ); Create_Operator_Button( Buttons(MINUS), "operatorMinus", Minus_charp ); Create_Operator_Button( Buttons(DIVIDE), "operatorDivide", Div_charp ); Create_Operator_Button( Buttons(MULTIPLY), "operatorDivide", Mult_charp ); Create_Digit_Button( Buttons('9'), "number9", Label => Nine_charp ); Create_Digit_Button( Buttons('8'), "number8", Label => Eight_charp ); Create_Digit_Button( Buttons('7'), "number7", Label => Seven_charp ); Create_Digit_Button( Buttons('6'), "number6", Label => Six_charp ); Create_Digit_Button( Buttons('5'), "number5", Label => Five_charp ); Create_Digit_Button( Buttons('4'), "number4", Label => Four_charp ); Create_Digit_Button( Buttons('3'), "number3", Label => Three_charp ); Create_Digit_Button( Buttons('2'), "number2", Label => Two_charp ); Create_Digit_Button( Buttons('1'), "number1", Label => One_charp ); --| special size buttons, either vertically or horizontally Create_Digit_Button( Buttons('0'), "number0", Zero_Charp, Width=> 78 ); --johndoe@inmet.com--Kirk Beitz--VOX:(619)683-3337 --FAX(619)683-2121-- --http://www.inmet.com/~johndoe/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Subprogram Renaming 1996-04-10 0:00 ` johndoe @ 1996-04-10 0:00 ` Norman H. Cohen 1996-04-11 0:00 ` Norman H. Cohen 0 siblings, 1 reply; 30+ messages in thread From: Norman H. Cohen @ 1996-04-10 0:00 UTC (permalink / raw) In article <kdd95h53l3.fsf@dsd.camb>, johndoe (johndoe) provided several good examples of renaming-as-body. This capability is especially useful when a subprogram is implemented using generic instantiation. For example: generic type Element_Type is private; package Generic_Dequeue_Object is pragma Elaborate_Body; procedure Add_To_Front (Item: in Element_Type); procedure Add_To_Back (Item: in Element_Type); procedure Remove_From_Front (Item: out Element_Type); procedure Remove_From_Back (Item: out Element_Type); end Generic_Dequeue_Object; package Integer_Stack_Object is procedure Push (Item: in Integer); procedure Pop (Item: out Integer); end Integer_Stack_Object; with Generic_Dequeue_Object; package body Integer_Stack_Object is package Integer_Dequeue_Object is new Generic_Dequeue_Object (Integer); procedure Push (Item: in Integer) renames Integer_Dequeue_Object.Add_To_Front; procedure Pop (Item: out Integer) renames Integer_Dequeue_Object.Remove_From_Front; end Integer_Stack_Object; -- Norman H. Cohen ncohen@watson.ibm.com ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Subprogram Renaming 1996-04-10 0:00 ` Norman H. Cohen @ 1996-04-11 0:00 ` Norman H. Cohen 1996-04-12 0:00 ` Jonas Nygren 0 siblings, 1 reply; 30+ messages in thread From: Norman H. Cohen @ 1996-04-11 0:00 UTC (permalink / raw) In article <4kgde6$q8t@watnews1.watson.ibm.com>, I wrote: |> This capability is especially |> useful when a subprogram is implemented using generic instantiation. Renaming-as-body is also useful in conjunction with derived subprograms. Here's a variation on my previous example: package Integer_Dequeues is type Dequeue_Type is private; procedure Add_To_Front (Dequeue: in out Dequeue_Type; Item: in Integer); procedure Add_To_Back (Dequeue: in out Dequeue_Type; Item: in Integer); procedure Remove_From_Front (Dequeue: in out Dequeue_Type; Item: out Integer); procedure Remove_From_Back (Dequeue: in out Dequeue_Type; Item: out Integer); private type Dequeue_Type is ...; end Integer_Dequeues; with Integer_Dequeues; package Integer_Stacks is type Stack_Type is private; procedure Push (Stack: in out Stack_Type; Item: in Integer); procedure Pop (Stack: in out Stack_Type; Item: out Integer); private use Integer_Dequeues; type Stack_Type is new Dequeue_Type; procedure Push (Stack: in out Stack_Type; Item: in Integer) renames Add_To_Front; procedure Pop (Stack: in out Stack_Type; Item: out Integer) renames Remove_From_Front; end Integer_Stacks; The subprograms being renamed are the inherited subprograms procedure Remove_From_Front (Dequeue: in out Stack_Type; Item: out Integer); procedure Remove_From_Back (Dequeue: in out Stack_Type; Item: out Integer); implicitly declared after the derived-type declaration in the private part. Because a renaming declaration acting as a subprogram declaration is allowed in the package declaration, Integer_Stacks does not even need a package body! -- Norman H. Cohen ncohen@watson.ibm.com ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Subprogram Renaming 1996-04-11 0:00 ` Norman H. Cohen @ 1996-04-12 0:00 ` Jonas Nygren 1996-04-12 0:00 ` Norman H. Cohen 0 siblings, 1 reply; 30+ messages in thread From: Jonas Nygren @ 1996-04-12 0:00 UTC (permalink / raw) Norman H. Cohen wrote: > > In article <4kgde6$q8t@watnews1.watson.ibm.com>, I wrote: > > |> This capability is especially > |> useful when a subprogram is implemented using generic instantiation. > > Renaming-as-body is also useful in conjunction with derived subprograms. > Here's a variation on my previous example: I have been experimenting with such a construct for some months but always encountered some new problem. My example code is similar to Normans but instead of Integer_Dequeues I have Generic_Dequeues and Generic_Stacks. My problem is how to handle a subprogram with the same name for Dequeue_Type and Stack_Type, e.g. Remove_All. I never managed to figure out how to handle the renaming. Perhaps somebody here can help me. I intersperse the added code in Normans example below. Of course I could introduce a dummy type with the common names marked to distinguish them from the intended name. Deque_Type and Stack_Type then derives from this 'dummy type'. Another note: As mentioned above my code uses generics while Norman's does not. Is there a catch? I encountered a problem with Gnat where it worked without generics but not with. I have reported it but have not heard anything from ACT (I am not on support contract :-). Is there Ada legal problems with adding generics to these example packages? /jonas > > package Integer_Dequeues is > type Dequeue_Type is private; > procedure Add_To_Front (Dequeue: in out Dequeue_Type; Item: in Integer); > procedure Add_To_Back (Dequeue: in out Dequeue_Type; Item: in Integer); > procedure Remove_From_Front > (Dequeue: in out Dequeue_Type; Item: out Integer); > procedure Remove_From_Back > (Dequeue: in out Dequeue_Type; Item: out Integer); procedure Remove_All (Dequeue: in out Dequeue_Type); > private > type Dequeue_Type is ...; > end Integer_Dequeues; > > with Integer_Dequeues; > package Integer_Stacks is > type Stack_Type is private; > procedure Push (Stack: in out Stack_Type; Item: in Integer); > procedure Pop (Stack: in out Stack_Type; Item: out Integer); procedure Remove_All (Stack: in out Stack_Type); > private > use Integer_Dequeues; > type Stack_Type is new Dequeue_Type; > procedure Push (Stack: in out Stack_Type; Item: in Integer) > renames Add_To_Front; > procedure Pop (Stack: in out Stack_Type; Item: out Integer) > renames Remove_From_Front; procedure Remove_All (Stack: in out Stack_Type) renames Remove_All; -- Does not work, -- Gnat e.g. creates a recursive call (reported) > end Integer_Stacks; > > The subprograms being renamed are the inherited subprograms > > procedure Remove_From_Front > (Dequeue: in out Stack_Type; Item: out Integer); > > procedure Remove_From_Back > (Dequeue: in out Stack_Type; Item: out Integer); > > implicitly declared after the derived-type declaration in the private > part. > > Because a renaming declaration acting as a subprogram declaration is > allowed in the package declaration, Integer_Stacks does not even need a > package body! > > -- > Norman H. Cohen ncohen@watson.ibm.com -- ------------------------------------------------------- -- Jonas Nygren -- ehsjony@ehs.ericsson.se ------------------------------------------------------- ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Subprogram Renaming 1996-04-12 0:00 ` Jonas Nygren @ 1996-04-12 0:00 ` Norman H. Cohen 1996-04-13 0:00 ` Robert A Duff 0 siblings, 1 reply; 30+ messages in thread From: Norman H. Cohen @ 1996-04-12 0:00 UTC (permalink / raw) In article <316E12F2.37BC@ehs.ericsson.se>, Jonas Nygren <ehsjony@ehs.ericsson.se> writes: |> > package Integer_Dequeues is |> > type Dequeue_Type is private; ... |> |> procedure Remove_All (Dequeue: in out Dequeue_Type); |> |> > private |> > type Dequeue_Type is ...; |> > end Integer_Dequeues; |> > |> > with Integer_Dequeues; |> > package Integer_Stacks is |> > type Stack_Type is private; ... |> |> procedure Remove_All (Stack: in out Stack_Type); |> |> > private |> > use Integer_Dequeues; |> > type Stack_Type is new Dequeue_Type; ... |> |> procedure Remove_All (Stack: in out Stack_Type) |> renames Remove_All; -- Does not work, |> -- Gnat e.g. creates a recursive call (reported) |> |> > end Integer_Stacks; The explicit declaration of Remove_All in the visible part of Integer_Stacks hides all homographs later in the same declaration, and the version implicitly declared after the derived-type declaration is a homograph of the explicitly declared version. Thus you're trying to rename the explicitly declared Remove_All as itself. Here's an ugly solution: package Integer_Stacks is type Stack_Type is private; ... procedure Remove_All (Stack: in out Stack_Type); private package Inner is type Stack_Parent_Type is new Integer_Dequeues.Dequeue_Type; procedure Parent_Remove_All (Stack: Stack_Parent_Type) renames Remove_All; ... end Inner; type Stack_Type is new Inner.Stack_Parent_Type; procedure Remove_All (Stack: in out Stack_Type) renames Parent_Remove_All; -- Inherited from Inner.Remove_All ... end Integer_Stacks; At least the ugliness is hidden in the private part and has no runtime overhead. -- Norman H. Cohen ncohen@watson.ibm.com ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Subprogram Renaming 1996-04-12 0:00 ` Norman H. Cohen @ 1996-04-13 0:00 ` Robert A Duff 1996-04-15 0:00 ` Norman H. Cohen 0 siblings, 1 reply; 30+ messages in thread From: Robert A Duff @ 1996-04-13 0:00 UTC (permalink / raw) In article <4kmgha$139s@watnews1.watson.ibm.com>, Norman H. Cohen <ncohen@watson.ibm.com> wrote: > procedure Remove_All (Stack: in out Stack_Type) > renames Parent_Remove_All; > -- Inherited from Inner.Remove_All Why not just: procedure Remove_All (Stack: in out Stack_Type) renames Inner.Remove_All; ? - Bob ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Subprogram Renaming 1996-04-13 0:00 ` Robert A Duff @ 1996-04-15 0:00 ` Norman H. Cohen 0 siblings, 0 replies; 30+ messages in thread From: Norman H. Cohen @ 1996-04-15 0:00 UTC (permalink / raw) In article <DprxrI.Dp3@world.std.com>, bobduff@world.std.com (Robert A Duff) writes: |> Why not just: |> |> procedure Remove_All (Stack: in out Stack_Type) |> renames Inner.Remove_All; |> |> ? That won't work. Inner.Remove_All has a Stack_Parent_Type parameter, not a Stack_Type parameter. The derived-type declaration for Stack_Type itself must be in the outer declarative region, where the private type declaration is. Thus the subprogram being renamed is not the one declared in the inner package, but the one derived from that in the outer package. package Integer_Stacks is type Stack_Type is private; ... procedure Remove_All (Stack: in out Stack_Type); private package Inner is type Stack_Parent_Type is new Integer_Dequeues.Dequeue_Type; procedure Parent_Remove_All (Stack: Stack_Parent_Type) renames Remove_All; ... end Inner; type Stack_Type is new Inner.Stack_Parent_Type; procedure Remove_All (Stack: in out Stack_Type) renames Parent_Remove_All; -- Inherited from Inner.Remove_All end Integer_Stacks; -- Norman H. Cohen ncohen@watson.ibm.com ^ permalink raw reply [flat|nested] 30+ messages in thread
[parent not found: <md5:046A59600C3FEFC327385C3E914D6997>]
* Re: Subprogram Renaming [not found] <md5:046A59600C3FEFC327385C3E914D6997> @ 1996-04-08 0:00 ` James A. Squire 1996-04-08 0:00 ` Robert Dewar 1996-04-09 0:00 ` Robert A Duff 0 siblings, 2 replies; 30+ messages in thread From: James A. Squire @ 1996-04-08 0:00 UTC (permalink / raw) On Sat, 6 Apr 1996 06:13:56, Robert Dewar <dewar@CS.NYU.EDU> wrote: > James Squire said > > "So I am totally at a loss to see how Ada95 added anything to the case > cited in 6.2 of the Rationale to allow you to do something you weren't > able to do in Ada83." > > I don't see this is so confusing in the Rationale. The new thing, as is > clear from your quote, is being allowed to use a subprogram renaming > declaration AS A BODY (in particular as a completion). And my question was, why does being able to rename a subprogram AS A BODY matter? What is so NEW about this? Why should I care about this NEW thing? > The notion (and syntax) of a subprogram renaming declaration of course > is not new, so there is no point in looking for a change in that section. Indeed, and why was this not considered sufficient? > But I realize that a lot of people need examples (I hate them :-) so > here is one: > > package q is > procedure j; > end q; > > package body q is > ... > procedure j renames k; which looks like a rename of a spec to me. I can do this in Ada83. > end q; -- James Squire MDA Avionics Tools & Processes ja_squire@csehp3.mdc.com "one of these days I'm going to better myself by going to Knight school" "You'll be a web knight instead of a web page!" ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Subprogram Renaming 1996-04-08 0:00 ` James A. Squire @ 1996-04-08 0:00 ` Robert Dewar 1996-04-09 0:00 ` Gary McKee 1996-04-09 0:00 ` Robert A Duff 1 sibling, 1 reply; 30+ messages in thread From: Robert Dewar @ 1996-04-08 0:00 UTC (permalink / raw) James Squire said "And my question was, why does being able to rename a subprogram AS A BODY matter? What is so NEW about this? Why should I care about this NEW thing?" Well any new feature may or may not be useful to you, but please study my example more carefully, you CANNOT do whyat I suggested in Ada 83. The new feature is, as shown in my example, the ability to provide a completion using a renaming, instead of a normal body. This saves having to write a junk wrapper routine with an extra call. It is most useful when used in the private part of a spec. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Subprogram Renaming 1996-04-08 0:00 ` Robert Dewar @ 1996-04-09 0:00 ` Gary McKee 0 siblings, 0 replies; 30+ messages in thread From: Gary McKee @ 1996-04-09 0:00 UTC (permalink / raw) In article <dewar.829015659@schonberg>, dewar@cs.nyu.edu (Robert Dewar) wrote: > James Squire said > > "And my question was, why does being able to rename a subprogram AS A > BODY matter? What is so NEW about this? Why should I care about this > NEW thing?" > > Well any new feature may or may not be useful to you, but please study > my example more carefully, you CANNOT do whyat I suggested in Ada 83. > > The new feature is, as shown in my example, the ability to provide a > completion using a renaming, instead of a normal body. This saves having > to write a junk wrapper routine with an extra call. > > It is most useful when used in the private part of a spec. -------------------------------------------------------- The rationale given when this change was submitted to the requirements team was as follows: The avowed purpose of a package specification is to offer a 'contract' for delivery of software services as implemented by the package body. When a subprogram is implemented via a renaming of another subprogram (procedure j renames k;), the 'contract' is compromised because the implementation must be placed in the specification. This is contrary to the paradigms of 'modularity, abstraction, and information hiding'. The workaround is, of course, the wrapper body in the package body. This adds complexity and potential error without increasing the quality, value, or ease of use of the language. The intent of this change was to permit EXACTLY the renaming that you used in your example: >> package q is >> procedure j; >> end q; >> >> package body q is >> ... >> procedure j renames k; This was not previously legal. I submitted the request for change because I was, at the time, teaching Ada83 full time for an aeorspace company and nearly every student sooner or later tried to do what you suggested in your example and I could never explain why it should be prohibited. Now, it is permitted, Yeah! -------------------------------------------------------------------- Gary McKee McKee Consulting gmckee@cloudnine.com P. O. Box 3009 voice: (303) 795-7287 Littleton, CO 80161-3009 WWW home page => <http://www.csn.net/~gmckee/> -------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Subprogram Renaming 1996-04-08 0:00 ` James A. Squire 1996-04-08 0:00 ` Robert Dewar @ 1996-04-09 0:00 ` Robert A Duff 1 sibling, 0 replies; 30+ messages in thread From: Robert A Duff @ 1996-04-09 0:00 UTC (permalink / raw) In article <316951C3.CE4@csehp3.mdc.com>, James A. Squire <m193884@CSEHP3.MDC.COM> wrote: >> package q is >> procedure j; >> end q; >> >> package body q is >> ... >> procedure j renames k; > >which looks like a rename of a spec to me. I can do this in Ada83. No, the above is illegal in Ada 83. In Ada 83, you have two declarations of J, which are homographs, and therefore illegal. And you have a missing body for the first J, which is also illegal. The new thing in Ada 95 is that the renaming can act as the body of the first J. This is no big deal -- the renaming is just a short-hand notation for "procedure j is begin k; end;". But it was illegal in Ada 83. As Robert Dewar said, this has nothing to do with syntax rules -- the syntax for renamings is the same. The difference is where they're allowed, and what they mean. To find the rules, you have to look at the text under subprogram renamings (as opposed to just looking at the BNF syntax rules). - Bob ^ permalink raw reply [flat|nested] 30+ messages in thread
[parent not found: <md5:C24D8C2EE138D9627FB8B93E2E35D9F3>]
* Subprogram Renaming [not found] <md5:C24D8C2EE138D9627FB8B93E2E35D9F3> @ 1996-04-05 0:00 ` James A. Squire 1996-04-06 0:00 ` Robert Dewar 0 siblings, 1 reply; 30+ messages in thread From: James A. Squire @ 1996-04-05 0:00 UTC (permalink / raw) According to section 6.2 of the Ada95 Rationale, "In Ada95, we allow a subprogram body to be provided by renaming another subprogram. This is a great convenience in those many cases in Ada83 where the programmer was forced to provide a body which simply called some other existing subprogram." In the Ada95 LRM, section 8.5 has: renaming_declaration ::= object_renaming_declaration |exception_renaming_declaration |package_renaming_declaration |subprogram_renaming_declaration |generic_renaming_declaration In the Ada83 LRM, the only thing not included in this syntax diagram was the "generic_renaming_declaration", which is not what 6.2 of the Rationale is talking about. So I am totally at a loss to see how Ada95 added anything to the case cited in 6.2 of the Rationale to allow you to do something you weren't able to do in Ada83. Can someone please help me understand this terribly confusing section of the Rationale? Thank you. -- James Squire MDA Avionics Tools & Processes ja_squire@csehp3.mdc.com "one of these days I'm going to better myself by going to Knight school" "You'll be a web knight instead of a web page!" ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Subprogram Renaming 1996-04-05 0:00 ` James A. Squire @ 1996-04-06 0:00 ` Robert Dewar 0 siblings, 0 replies; 30+ messages in thread From: Robert Dewar @ 1996-04-06 0:00 UTC (permalink / raw) James Squire said "So I am totally at a loss to see how Ada95 added anything to the case cited in 6.2 of the Rationale to allow you to do something you weren't able to do in Ada83." I don't see this is so confusing in the Rationale. The new thing, as is clear from your quote, is being allowed to use a subprogram renaming declaration AS A BODY (in particular as a completion). The notion (and syntax) of a subprogram renaming declaration of course is not new, so there is no point in looking for a change in that section. But I realize that a lot of people need examples (I hate them :-) so here is one: package q i procedure j; end q; package body q is ... procedure j renames k; end q; ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~1996-04-15 0:00 UTC | newest] Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <md5:95D854EBD1A47E0E86027A3CC7DBD9A4> 1996-04-10 0:00 ` Subprogram Renaming James A. Squire 1996-04-10 0:00 ` Robert A Duff 1996-04-11 0:00 ` Adam Beneschan 1996-04-11 0:00 ` Robert Dewar 1996-04-11 0:00 ` Robert A Duff 1996-04-10 0:00 ` Robert Dewar 1996-04-11 0:00 ` Jonas Nygren 1996-04-11 0:00 ` Robert Dewar 1996-04-12 0:00 ` Jonas Nygren 1996-04-10 0:00 ` johndoe [not found] <md5:3CC2294B6049DDBD8790280EABCEDE81> 1996-04-12 0:00 ` James A. Squire [not found] <md5:87494FB95037B9578F62831DE10B6BB3> 1996-04-10 0:00 ` James A. Squire [not found] <md5:88A5E8822105A2023A0A951BB5EC646E> 1996-04-10 0:00 ` James A. Squire [not found] <md5:FE4AB546A8392541EDC1E3FE12E3D8AF> 1996-04-09 0:00 ` James A. Squire 1996-04-09 0:00 ` Robert Dewar 1996-04-10 0:00 ` Robert A Duff 1996-04-11 0:00 ` Mark A Biggar 1996-04-10 0:00 ` johndoe 1996-04-10 0:00 ` Norman H. Cohen 1996-04-11 0:00 ` Norman H. Cohen 1996-04-12 0:00 ` Jonas Nygren 1996-04-12 0:00 ` Norman H. Cohen 1996-04-13 0:00 ` Robert A Duff 1996-04-15 0:00 ` Norman H. Cohen [not found] <md5:046A59600C3FEFC327385C3E914D6997> 1996-04-08 0:00 ` James A. Squire 1996-04-08 0:00 ` Robert Dewar 1996-04-09 0:00 ` Gary McKee 1996-04-09 0:00 ` Robert A Duff [not found] <md5:C24D8C2EE138D9627FB8B93E2E35D9F3> 1996-04-05 0:00 ` James A. Squire 1996-04-06 0:00 ` Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox