Re: Subprogram Renaming

["James A. Squire" <m193884@CSEHP3.MDC.COM>]

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