From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,LOTS_OF_MONEY autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ac5c3bc59168d76 X-Google-Attributes: gid103376,public From: "James A. Squire" Subject: Re: Subprogram Renaming Date: 1996/04/10 Message-ID: <316BC3D6.14E7@csehp3.mdc.com> X-Deja-AN: 146749092 sender: Ada programming language references: comments: Gated by NETNEWS@AUVM.AMERICAN.EDU content-type: text/plain; charset=us-ascii organization: MDA Avionics Tools & Processes mime-version: 1.0 newsgroups: comp.lang.ada x-mailer: Mozilla 2.01 (X11; I; HP-UX A.09.01 9000/715) Date: 1996-04-10T00:00:00+00:00 List-Id: 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" > 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 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!"