Subprogram Renaming

Subprogram Renaming

[James A. Squire]

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

Re: Subprogram Renaming

[Robert Dewar]

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;

Re: Subprogram Renaming

[James A. Squire]

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

Re: Subprogram Renaming

[Robert Dewar]

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.

Re: Subprogram Renaming

[Gary McKee]

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/>
--------------------------------------------------------------------

Re: Subprogram Renaming

[James A. Squire]

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

Re: Subprogram Renaming

[Robert Dewar]

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.

Re: Subprogram Renaming

[Robert A Duff]

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

Re: Subprogram Renaming

[James A. Squire]

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

Re: Subprogram Renaming

[johndoe]

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

Re: Subprogram Renaming

[Robert A Duff]

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

Re: Subprogram Renaming

[James A. Squire]

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

Re: Subprogram Renaming

[Robert Dewar]

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.

Re: Subprogram Renaming

[johndoe]

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/

Re: Subprogram Renaming

[Robert A Duff]

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.  :-(

Re: Subprogram Renaming

[Norman H. Cohen]

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

Re: Subprogram Renaming

[James A. Squire]

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

Re: Subprogram Renaming

[Jonas Nygren]

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

Re: Subprogram Renaming

[Robert Dewar]

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.

Re: Subprogram Renaming

[Mark A Biggar]

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

Re: Subprogram Renaming

[Norman H. Cohen]

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

Re: Subprogram Renaming

[Adam Beneschan]

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

Re: Subprogram Renaming

[Robert A Duff]

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

Re: Subprogram Renaming

[Robert Dewar]

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!

Re: Subprogram Renaming

[Jonas Nygren]

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

Re: Subprogram Renaming

[Jonas Nygren]

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

Re: Subprogram Renaming

[James A. Squire]

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

Re: Subprogram Renaming

[Norman H. Cohen]

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

Re: Subprogram Renaming

[Robert A Duff]

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

Re: Subprogram Renaming

[Norman H. Cohen]

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