Will "renames" increase program size?

Will "renames" increase program size?

[Adrian Hoe]

Hi,

Just out of curiosity, will "renames" increase program size?

e,g,

package A renames Ada.Text_IO;

P : Person_Rec renames Personnel_Record;

I presume Ada compiler will replace the names just like #define in C,
so no increase in program size. But I just want to be sure.

Thanks.
--
Adrian Hoe
http://adrianhoe.com/adrianhoe

Re: Will "renames" increase program size?

[Randy Brukardt]

"Adrian Hoe" <abyhoe@gmail.com> wrote in message 
news:46294109-f07d-49c0-8e81-65a369a05ced@z15g2000prn.googlegroups.com...
> Hi,
>
> Just out of curiosity, will "renames" increase program size?
>
> e,g,
>
> package A renames Ada.Text_IO;
>
> P : Person_Rec renames Personnel_Record;
>
> I presume Ada compiler will replace the names just like #define in C,
> so no increase in program size. But I just want to be sure.

It depends on what you rename. If you rename something that requires runtime 
evaluation, then there will be a small amount of overhead to do that 
evaluation and save the result. But most renames don't need to do that.

Some examples where there probably would be some overhead:

             Obj : Natural renames My_Array (Some_Variable).all;
             Obj2 : Float renames Some_Function (A, B);

Recall that a renames is only evaluated once, at the point of the renames. 
You can use this to shrike code size as well (if the item renamed is 
expensive to evaluate and it is referenced multiple times).

                                   Randy.

Re: Will "renames" increase program size?

[AdaMagica]

Additionally to Randy's answer: IIRC, renaming a primitive operation
adds an entry to the dispatch table, and the original and the renamed
operation may be overridden with different operations upon derivation.

Re: Will "renames" increase program size?

[Yannick Duchêne (Hibou57)]

Le Wed, 15 Jun 2011 11:11:16 +0200, AdaMagica  
<christ-usch.grein@t-online.de> a écrit:

> Additionally to Randy's answer: IIRC, renaming a primitive operation
> adds an entry to the dispatch table, and the original and the renamed
> operation may be overridden with different operations upon derivation.

Oh, I was not aware of that. Thanks for the important point!


-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]
“c++; /* this makes c bigger but returns the old value */” [Anonymous]

Re: Will "renames" increase program size?

[Yannick Duchêne (Hibou57)]

Le Wed, 15 Jun 2011 07:37:22 +0200, Randy Brukardt <randy@rrsoftware.com>  
a écrit:
> Some examples where there probably would be some overhead:
>
>              Obj : Natural renames My_Array (Some_Variable).all;
>              Obj2 : Float renames Some_Function (A, B);
>
Yes, because this is more an aliasing (in the symbolic sense) than a  
proper renaming.

-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]
“c++; /* this makes c bigger but returns the old value */” [Anonymous]

Re: Will "renames" increase program size?

[Dmitry A. Kazakov]

On Wed, 15 Jun 2011 13:24:52 +0200, Yannick Duchêne (Hibou57) wrote:

> Le Wed, 15 Jun 2011 07:37:22 +0200, Randy Brukardt <randy@rrsoftware.com>  
> a écrit:
>> Some examples where there probably would be some overhead:
>>
>>              Obj : Natural renames My_Array (Some_Variable).all;
>>              Obj2 : Float renames Some_Function (A, B);
>>
> Yes, because this is more an aliasing (in the symbolic sense) than a  
> proper renaming.

Yes, Ada's renaming is not renaming. Consider this:

   Line : String renames Get_Line;

It calls Get_Line once and keeps the result object. In fact it is an
equivalent to:

   <anonymous> : constant String := Get_Line;
   Line : properly renames <anonymous>;

Consider also the effect of renaming on the visibility rules:

   package P1 is
      End_Error : exception renames Ada.Text_IO.End_Error;
   end P1;
   package P2 is
      End_Error : exception renames Ada.Text_IO.End_Error;
   end P2;
   use P1, P2;
   
   exception
      when End_Error => -- End_Error is hidden!

Ada's "renames" does not rename here, it copies, creates objects. There are
three End_Error here, all of them are equal, but not same:

exception
   when Ada.Text_IO.End_Error =>
      ...
   when P1.End_Error => -- Error! P1.End_Error has the same value
      ...
   when P2.End_Error =>
      ...

A proper renaming would create identical (x≡y) entities, Ada's renaming
sometimes creates only equal ones (x=y).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Will "renames" increase program size?

[AdaMagica]

On 15 Jun., 15:15, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Wed, 15 Jun 2011 13:24:52 +0200, Yannick Duchêne (Hibou57) wrote:
> > Le Wed, 15 Jun 2011 07:37:22 +0200, Randy Brukardt <ra...@rrsoftware.com>  
> > a écrit:
> >> Some examples where there probably would be some overhead:
>
> >>              Obj : Natural renames My_Array (Some_Variable).all;
> >>              Obj2 : Float renames Some_Function (A, B);
>
> > Yes, because this is more an aliasing (in the symbolic sense) than a  
> > proper renaming.
>
> Yes, Ada's renaming is not renaming. Consider this:
>
>    Line : String renames Get_Line;
>
> It calls Get_Line once and keeps the result object. In fact it is an
> equivalent to:
>
>    <anonymous> : constant String := Get_Line;
>    Line : properly renames <anonymous>;
>
> Consider also the effect of renaming on the visibility rules:
>
>    package P1 is
>       End_Error : exception renames Ada.Text_IO.End_Error;
>    end P1;
>    package P2 is
>       End_Error : exception renames Ada.Text_IO.End_Error;
>    end P2;
>    use P1, P2;
>
>    exception
>       when End_Error => -- End_Error is hidden!
>
> Ada's "renames" does not rename here, it copies, creates objects. There are
> three End_Error here, all of them are equal, but not same:
>
> exception
>    when Ada.Text_IO.End_Error =>
>       ...
>    when P1.End_Error => -- Error! P1.End_Error has the same value
>       ...
>    when P2.End_Error =>
>       ...
>
> A proper renaming would create identical (x≡y) entities, Ada's renaming
> sometimes creates only equal ones (x=y).
>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de

That's not correct. A renaming does not copy nor somehow create new
entities, it only creates new names for the same thing. Since
visibility is via names, you arrive at unresolvability issues.

Re: Will "renames" increase program size?

[Dmitry A. Kazakov]

On Wed, 15 Jun 2011 23:59:35 -0700 (PDT), AdaMagica wrote:

> On 15 Jun., 15:15, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Wed, 15 Jun 2011 13:24:52 +0200, Yannick Duchêne (Hibou57) wrote:
>>> Le Wed, 15 Jun 2011 07:37:22 +0200, Randy Brukardt <ra...@rrsoftware.com>  
>>> a écrit:
>>>> Some examples where there probably would be some overhead:
>>
>>>>              Obj : Natural renames My_Array (Some_Variable).all;
>>>>              Obj2 : Float renames Some_Function (A, B);
>>
>>> Yes, because this is more an aliasing (in the symbolic sense) than a  
>>> proper renaming.
>>
>> Yes, Ada's renaming is not renaming. Consider this:
>>
>>    Line : String renames Get_Line;
>>
>> It calls Get_Line once and keeps the result object. In fact it is an
>> equivalent to:
>>
>>    <anonymous> : constant String := Get_Line;
>>    Line : properly renames <anonymous>;
>>
>> Consider also the effect of renaming on the visibility rules:
>>
>>    package P1 is
>>       End_Error : exception renames Ada.Text_IO.End_Error;
>>    end P1;
>>    package P2 is
>>       End_Error : exception renames Ada.Text_IO.End_Error;
>>    end P2;
>>    use P1, P2;
>>
>>    exception
>>       when End_Error => -- End_Error is hidden!
>>
>> Ada's "renames" does not rename here, it copies, creates objects. There are
>> three End_Error here, all of them are equal, but not same:
>>
>> exception
>>    when Ada.Text_IO.End_Error =>
>>       ...
>>    when P1.End_Error => -- Error! P1.End_Error has the same value
>>       ...
>>    when P2.End_Error =>
>>       ...
>>
>> A proper renaming would create identical (x≡y) entities, Ada's renaming
>> sometimes creates only equal ones (x=y).
>>
>> --
>> Regards,
>> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de
> 
> That's not correct. A renaming does not copy nor somehow create new
> entities, it only creates new names for the same thing. Since
> visibility is via names, you arrive at unresolvability issues.

No. First, sometimes it certainly copies, e.g. when the function's result
is renamed, the result (temporary object) is copied. The compiler might
optimize the temporary object away, or even mandated to do so for limited
results, but *semantically* it is a copy.

Compare it with array indexing, which is a properly renamed result, as a
lazy expression or using aliasing.

The wisdom of allowing renaming function results is questionable, but if
allowed it should be lazy. Laziness could also solve this disgrace of Ada's
renaming:

with Ada.Text_IO;  use Ada.Text_IO;

procedure Shame is
   type T is array (Integer range <>) of Integer;
   A : T := (0 => 0, 1 => 1);
   subtype S is T (1..2);
   B : S renames A;
begin
   Put_Line (Integer'Image (B (0))); -- Surprise, 0 is a legal index of S!
end Shame;

Regarding the visibility rules, the design bug is that the new name of a
thing shall not hide any other names of it in any context. In the example
above P1.End_Error should not have hidden P2.End_Error. (I don't know why
this has not been fixed long time ago, because it would be a really minor
language change, which would not break any existing code).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Will "renames" increase program size?

[AdaMagica]

> No. First, sometimes it certainly copies, e.g. when the function's result
> is renamed, the result (temporary object) is copied. The compiler might
> optimize the temporary object away, or even mandated to do so for limited
> results, but *semantically* it is a copy.

OK, agreed, there are cases  where rename does a copy.

> procedure Shame is
>    type T is array (Integer range <>) of Integer;
>    A : T := (0 => 0, 1 => 1);
>    subtype S is T (1..2);
>    B : S renames A;
> begin
>    Put_Line (Integer'Image (B (0))); -- Surprise, 0 is a legal index of S!
> end Shame;

Yes, agreed, that's annoying and confusing. Perhaps such a renaming
should be forbidden. Don't know what other consequences such a rule
would have, which other rules would have to be adapted. Think of
generics... (I know you dislike generics.)

> Regarding the visibility rules, the design bug is that the new name of a
> thing shall not hide any other names of it in any context. In the example
> above P1.End_Error should not have hidden P2.End_Error. (I don't know why
> this has not been fixed long time ago, because it would be a really minor
> language change, which would not break any existing code).

You request that resolution would not be via names, but via entities.
Thus when there are several homonymes visible at the same time, the
compiler would have to check whether all these names actually specify
the same entity. Don't know whether this would make overload
resolution more difficult.

Re: Will "renames" increase program size?

[Dmitry A. Kazakov]

On Thu, 16 Jun 2011 03:18:14 -0700 (PDT), AdaMagica wrote:

>> procedure Shame is
>> � �type T is array (Integer range <>) of Integer;
>> � �A : T := (0 => 0, 1 => 1);
>> � �subtype S is T (1..2);
>> � �B : S renames A;
>> begin
>> � �Put_Line (Integer'Image (B (0))); -- Surprise, 0 is a legal index of S!
>> end Shame;
> 
> Yes, agreed, that's annoying and confusing. Perhaps such a renaming
> should be forbidden. Don't know what other consequences such a rule
> would have, which other rules would have to be adapted. Think of
> generics... (I know you dislike generics.)

(:-))

I think it would be difficult to forbid, because renaming that changes view
is extremely useful for tagged types. E.g.

   if X in S'Class then
      declare
         Y : S'Class renames S'Class (X);
      begin

I always wished a cleaner and safer construct for this, then we could
indeed disable renaming to a view altogether.

Luckily, this one is illegal:

   type T is access all Integer;
   subtype S is not null T;
   P1 : T := null;
   P2 : S renames S (P1);

>> Regarding the visibility rules, the design bug is that the new name of a
>> thing shall not hide any other names of it in any context. In the example
>> above P1.End_Error should not have hidden P2.End_Error. (I don't know why
>> this has not been fixed long time ago, because it would be a really minor
>> language change, which would not break any existing code).
> 
> You request that resolution would not be via names, but via entities.
> Thus when there are several homonymes visible at the same time, the
> compiler would have to check whether all these names actually specify
> the same entity.

Yes.

> Don't know whether this would make overload
> resolution more difficult.

Maybe it would not, because the actions need only to be undertaken when a
conflict is detected. Then the compiler would weed the list of conflicting
names of same entities. That should not even slower the compilation
(provided the feature would not be abused).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Will "renames" increase program size?

[Randy Brukardt]

"AdaMagica" <christ-usch.grein@t-online.de> wrote in message 
news:4bdd2495-fb00-4aa7-89bd-910dfefa3704@i4g2000yqg.googlegroups.com...
>> procedure Shame is
>> type T is array (Integer range <>) of Integer;
>> A : T := (0 => 0, 1 => 1);
>> subtype S is T (1..2);
>> B : S renames A;
>> begin
>> Put_Line (Integer'Image (B (0))); -- Surprise, 0 is a legal index of S!
>> end Shame;
>
>Yes, agreed, that's annoying and confusing. Perhaps such a renaming
>should be forbidden. Don't know what other consequences such a rule
>would have, which other rules would have to be adapted. Think of
>generics... (I know you dislike generics.)

Everyone agrees that this was a mistake of Ada 83, mainly because it didn't 
have the concept of static matching. (Someone dug up the 1983 e-mail thread 
that led to this mistaken rule.) However, fixing it would be widely 
incompatible -- for instance, virtually all renames of operators would be 
illegal under a matching rule (their parameters would need to be T'Base, but 
hardly anyone actually writes that). We've looked at rules that would be 
less incompatible, but they get very complex and it just didn't seem worth 
the headaches.

We've discussed this before on comp.lang.ada (I don't recall exactly when).

                             Randy.

Re: Will "renames" increase program size?

[Adam Beneschan]

On Jun 16, 1:59 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
>
> > That's not correct. A renaming does not copy nor somehow create new
> > entities, it only creates new names for the same thing. Since
> > visibility is via names, you arrive at unresolvability issues.
>
> No. First, sometimes it certainly copies, e.g. when the function's result
> is renamed, the result (temporary object) is copied. The compiler might
> optimize the temporary object away, or even mandated to do so for limited
> results, but *semantically* it is a copy.

I don't think that's right.  The test would be:

   type T1 is new Ada.Finalization.Controlled with record
      F1 : Integer;
   end record;
   overriding
   procedure Adjust (Obj : in out T1);

   function Func (N : Integer) return T1 is
   begin
      return Ret : T1 do
         T1.F1 := N;
      end return;
   end Func;

   procedure Proc is
      R : T1 renames Func(3);
   begin
      ...
   end Proc;

In this example, I believe that the renaming declaration cannot
legally cause Adjust to be called.  (This is in contrast with

      R : T1 := Func(3);

in which case the semantics specify that Adjust should be called, but
I think there are implementation permissions that would allow the
compiler to optimize the Adjust away.)

In the renaming case, as I read the RM, the extended return creates a
return object, the function call denotes a constant view of the return
object, and the renaming denotes a new view of the return object.
There's no copying or assignment involved.  (Of course, the compiler
could generate some sort of block-copy to implement this, but I think
we're talking about Ada semantics.  I don't think our compiler
generates a block copy.)

                                     -- Adam

Re: Will "renames" increase program size?

[Dmitry A. Kazakov]

On Thu, 16 Jun 2011 08:40:41 -0700 (PDT), Adam Beneschan wrote:

> On Jun 16, 1:59�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>>
>>> That's not correct. A renaming does not copy nor somehow create new
>>> entities, it only creates new names for the same thing. Since
>>> visibility is via names, you arrive at unresolvability issues.
>>
>> No. First, sometimes it certainly copies, e.g. when the function's result
>> is renamed, the result (temporary object) is copied. The compiler might
>> optimize the temporary object away, or even mandated to do so for limited
>> results, but *semantically* it is a copy.
> 
> I don't think that's right.  The test would be:
> 
>    type T1 is new Ada.Finalization.Controlled with record
>       F1 : Integer;
>    end record;
>    overriding
>    procedure Adjust (Obj : in out T1);
> 
>    function Func (N : Integer) return T1 is
>    begin
>       return Ret : T1 do
>          T1.F1 := N;
>       end return;
>    end Func;
> 
>    procedure Proc is
>       R : T1 renames Func(3);
>    begin
>       ...
>    end Proc;
> 
> In this example, I believe that the renaming declaration cannot
> legally cause Adjust to be called.

I.e. the optimization is mandated for all tagged types in presence of
return statement. Nevertheless Func creates a new object, which is then
renamed.

> In the renaming case, as I read the RM, the extended return creates a
> return object, the function call denotes a constant view of the return
> object, and the renaming denotes a new view of the return object.
> There's no copying or assignment involved.  (Of course, the compiler
> could generate some sort of block-copy to implement this, but I think
> we're talking about Ada semantics.

Semantically returning result of a function is always copying because the
object being returned changes the scope. You have a fully constructed
object #1 within the scope of the return statement. You have a fully
constructed object #2 in the scope of the function call. These are
semantically two different objects because scopes are different. That both
objects might share the same physical memory and therefore no physical
copying is needed, looks like an implementation detail to me.

Of course an alternative point of view is also possible: the object is
rather a closure which floats from one scope to another remaining "same".
But I think that this logical model is unnatural to Ada, and does not work
with by-value types anyway.

I think this could be analogous to inlined bodies. A call is semantically a
call even though nothing is actually called.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Will "renames" increase program size?

[Adam Beneschan]

On Jun 16, 9:33 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
>
> > In this example, I believe that the renaming declaration cannot
> > legally cause Adjust to be called.
>
> I.e. the optimization is mandated for all tagged types in presence of
> return statement. Nevertheless Func creates a new object, which is then
> renamed.

It is not a mandated optimization, because if you follow the semantics
in the RM, the example involves no *assignment* to be optimized away.

I'm having difficulty responding to your points, because you seem to
be defining terms with regard to how you see the world and what
pictures go on in your head when you think about a program's
semantics.  So in this context, I can kind of understand why you'd
think of a "return object" as somehow belonging inside the function
and thus being a separate object from the object that holds the
function result from the caller's point of view.  And in this view,
sure, there would be a copy.  But all this is just based on how you
see the world, not on anything objective.  The only really objective
definitions we have here are the ones given by the RM.  And in the
world according to the RM, there is only one object (the return
object, which has multiple different "views" that are given different
names, but is still only one object and thus there's no copying going
on).  I can understand why you might look at things differently; but
it's hard for me to see how any conclusions that you draw, that are
based on your own meanings of the terms derived from your own pictures
of the world, are going to be of much use to anyone else.

                                -- Adam

Re: Will "renames" increase program size?

[Dmitry A. Kazakov]

On Thu, 16 Jun 2011 10:42:01 -0700 (PDT), Adam Beneschan wrote:

> you seem to
> be defining terms with regard to how you see the world and what
> pictures go on in your head when you think about a program's
> semantics.

How could it be otherwise?

> So in this context, I can kind of understand why you'd
> think of a "return object" as somehow belonging inside the function
> and thus being a separate object from the object that holds the
> function result from the caller's point of view.  And in this view,
> sure, there would be a copy.  But all this is just based on how you
> see the world, not on anything objective.  The only really objective
> definitions we have here are the ones given by the RM.

How would you define a "language design bug" based on the RM itself?

Renaming in Ada has problems with its semantics, same is true for the
return statement, in my opinion. This opinion cannot be based on the RM. It
is based on an interpretation of the RM in some much wider context. Call it
confusion or common sense, no matter. You might think that in your opinion
Ada's renaming is just perfect. But exactly like mine your opinion is also
based on your world view rather than on the RM.

It would be useless to discuss Ada's concept of renaming (or function
result, or anything else) in the terms of the RM, because in this context
it neither right or wrong, it just is as it is.

> I can understand why you might look at things differently; but
> it's hard for me to see how any conclusions that you draw, that are
> based on your own meanings of the terms derived from your own pictures
> of the world, are going to be of much use to anyone else.

It is good enough to me, that you can understand why I see problems with
renaming.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Will "renames" increase program size?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:welpqz29i316$.10qazzjvlklcp$.dlg@40tude.net...
...
> It would be useless to discuss Ada's concept of renaming (or function
> result, or anything else) in the terms of the RM, because in this context
> it neither right or wrong, it just is as it is.

Not at all. We spend hundreds of hours a year talking about things like 
renames in terms of the RM. Moreover, when you are using terminology defined 
by the RM (like "copy", "renames", "return object", "temporary object"), 
it's likely that people (especially Adam and I) will think you are talking 
in those terms. And a renaming (in RM terms) is never a copy.

If you're going to use RM-defined concepts and ignore the RM definition, 
then you ought to clearly say so so that there is less confusion. And you're 
seriously confused on how these things work.

>Semantically returning result of a function is always copying because the
>object being returned changes the scope.

"Changing scope" doesn't require a copy in either RM or some sort of outside 
logical universe. The only thing that the "scope" of an object controls is 
when it is finalized, and that has nothing to do with the contents (from a 
logical perspective) of the object. (If the implementation uses some 
pointers or something for this purpose, that is merely an implementation 
detail and has no effect on the logical properties.) Ada indeed requires 
that this be a single object (so that 'Access works). In further cases, Ada 
requires that the anonymous object "mutate" into the target object with no 
copying ("built-in-place"); this too changes scope.

The point is that copying has a visible semantic effect, and implementations 
cannot just copy things whenever they feel like it -- its only allowed in 
certain cases.

In Ada 95 and 2005, this was supposedly an optimization, but that model 
simply does not work and has been abandoned in favor of requirements to not 
copy. (That was years ago, with a binding interpretation AI05-0067-1.) There 
is still a permission to not copy in some other cases.

                                                Randy.

Re: Will "renames" increase program size?

[Dmitry A. Kazakov]

On Thu, 16 Jun 2011 18:39:35 -0500, Randy Brukardt wrote:

>>Semantically returning result of a function is always copying because the
>>object being returned changes the scope.
> 
> "Changing scope" doesn't require a copy in either RM or some sort of outside 
> logical universe. The only thing that the "scope" of an object controls is 
> when it is finalized, and that has nothing to do with the contents (from a 
> logical perspective) of the object.

I fail to see how finalization could have nothing to do with the contents.
Finalized objects have no contents, they do not even exist.

> In further cases, Ada 
> requires that the anonymous object "mutate" into the target object with no 
> copying ("built-in-place"); this too changes scope.

Yep, "mutating", that is the term of the RM, I should have used instead of
"copying"! (:-))

So, the correct statement should have been: when the result of a function
is renamed it *mutates* into the target of renaming. Hmm, what is the RM
term for a non-existent thing?

(And some functions do not "return", they "build"!)

> The point is that copying has a visible semantic effect,

The cases under consideration are ones where copying should have no
semantic effect, e.g. parameter passing.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Will "renames" increase program size?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:12lr1j2mmzidu.18gjo4p3e73kk$.dlg@40tude.net...
> On Thu, 16 Jun 2011 18:39:35 -0500, Randy Brukardt wrote:
>
>>>Semantically returning result of a function is always copying because the
>>>object being returned changes the scope.
>>
>> "Changing scope" doesn't require a copy in either RM or some sort of 
>> outside
>> logical universe. The only thing that the "scope" of an object controls 
>> is
>> when it is finalized, and that has nothing to do with the contents (from 
>> a
>> logical perspective) of the object.
>
> I fail to see how finalization could have nothing to do with the contents.
> Finalized objects have no contents, they do not even exist.

Sorry, you need the read the RM again. Finalization is a process that 
happens on objects that exist, and it has no effect on whether they exist or 
not. Typically, they cease to exist later (how much later depends on where 
they are declared).

In particular, there is nothing necessarily wrong with accessing a finalized 
object; this allows objects to have circular dependencies and the like. This 
means, for instance, that an implementation should not deallocate part of an 
object when it is finalized (it is OK for the user to do that); for 
instance, the finalization of a dynamically bounded array object cannot 
include the implementation deallocating the associated memory -- that has to 
be done later. (Janus/Ada gets this wrong, although no one has ever reported 
a bug based on it, which shows the importance...)

Admittedly, a bit strange, but that's the rule.

...
>> The point is that copying has a visible semantic effect,
>
> The cases under consideration are ones where copying should have no
> semantic effect, e.g. parameter passing.

Last I recall, we were talking about renames, which never copy anything. 
Don't recall any discussion whatsoever about parameter passing. But if 
parameter passing does in fact do a copy, then there is a semantic effect 
(on aliasing at the very least).

It's pretty hard to do anything in a language definition without there being 
a semantic effect. Even when you think there isn't one, clever people like 
Adam and Steve Baird will show you one in some convoluted case. (Steve was 
just bending my ear about 'Unchecked_Access causing overhead when used to 
return an object of a local tagged type.)

                            Randy.

Re: Will "renames" increase program size?

[Dmitry A. Kazakov]

On Fri, 17 Jun 2011 19:02:49 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:12lr1j2mmzidu.18gjo4p3e73kk$.dlg@40tude.net...
>> On Thu, 16 Jun 2011 18:39:35 -0500, Randy Brukardt wrote:
>>
>>>>Semantically returning result of a function is always copying because the
>>>>object being returned changes the scope.
>>>
>>> "Changing scope" doesn't require a copy in either RM or some sort of outside
>>> logical universe. The only thing that the "scope" of an object controls is
>>> when it is finalized, and that has nothing to do with the contents (from a
>>> logical perspective) of the object.
>>
>> I fail to see how finalization could have nothing to do with the contents.
>> Finalized objects have no contents, they do not even exist.
> 
> Sorry, you need the read the RM again. Finalization is a process that 
> happens on objects that exist, and it has no effect on whether they exist or 
> not. Typically, they cease to exist later (how much later depends on where 
> they are declared).

Semantically finalized [typed] object does not exist. Object /= memory
allocated for it.

> In particular, there is nothing necessarily wrong with accessing a finalized 
> object; this allows objects to have circular dependencies and the like.

That would be a partial finalization. E.g. when the derived type's
finalization has been completed, the base's operations might still be
accessible. At this point the object of the derived type no more exists
[semantically].

>>> The point is that copying has a visible semantic effect,
>>
>> The cases under consideration are ones where copying should have no
>> semantic effect, e.g. parameter passing.
> 
> Last I recall, we were talking about renames, which never copy anything.

Some renames copy, some do not. Consider this example:

   type T is new Ada.Finalization.Controlled ...;
   function Foo return T;

   X : T renames Foo;

Does this copy? It seems that according to you, you cannot tell without
looking into the body of Foo:

   function Foo return T is -- This copies
      Result : T;
   begin
      return T;
   end Foo;

   function Foo return T is -- This does not copy
   begin
      return Result : T;
   end Foo;

Implementation-dependent semantics is not that good idea.

In my view any function always copies no matter what. Even when no Adjust
is called because it happened that the object created for rename shared the
memory with the function result. Even if it was inlined and optimized away
completely, semantically, it is still a copy.

That Ada's designer possibly thought otherwise, constitutes, in my opinion,
a language design bug (e.g. bogus limited-valued functions).

> Don't recall any discussion whatsoever about parameter passing. But if 
> parameter passing does in fact do a copy, then there is a semantic effect 
> (on aliasing at the very least).

No, because an attempt to exploit this effect is an error. Semantics does
not apply to erroneous programs, which is after all, why they are
erroneous.

> It's pretty hard to do anything in a language definition without there being 
> a semantic effect. Even when you think there isn't one, clever people like 
> Adam and Steve Baird will show you one in some convoluted case. (Steve was 
> just bending my ear about 'Unchecked_Access causing overhead when used to 
> return an object of a local tagged type.)

One might need to generate some code in order to ensure *absence* of any
semantic effect.

P.S. It seems that you use the word "semantic" as an equivalent to "code"
(a meaning to the machine). I used it as a meaning to the programmer.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Will "renames" increase program size?

[Yannick Duchêne (Hibou57)]

Le Sat, 18 Jun 2011 09:54:29 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> Does this copy? It seems that according to you, you cannot tell without
> looking into the body of Foo:
>
>    function Foo return T is -- This copies
>       Result : T;
>    begin
>       return T;
>    end Foo;
>
>    function Foo return T is -- This does not copy
>    begin
>       return Result : T;
>    end Foo;

May be I did not really understood what you meant, but a simple test  
program shows this makes no difference:


    -- Begin Test.adb  
------------------------------------------------------------

    with Ada.Text_IO;

    procedure Test is

       Foo_1_Seed : Integer := 0;

       function Foo_1 return Integer
       is
          Result : constant Integer := Foo_1_Seed;
       begin
          Foo_1_Seed := Foo_1_Seed + 1;
          return Result;
       end;

       Foo_2_Seed : Integer := 0;

       function Foo_2 return Integer is
       begin
          return Result : constant Integer := Foo_2_Seed do
             Foo_2_Seed := Foo_2_Seed + 1;
          end return;
       end;

       Foo_1_1 : Integer renames Foo_1;
       Foo_1_2 : Integer renames Foo_1;
       Foo_1_3 : Integer renames Foo_1;

       Foo_2_1 : Integer renames Foo_2;
       Foo_2_2 : Integer renames Foo_2;
       Foo_2_3 : Integer renames Foo_2;

       procedure Put (Label : in String; Value : in Integer) is
          package Text_IO renames Ada.Text_IO;
          package Integer_IO is new Ada.Text_IO.Integer_IO (Integer);
       begin
          Text_IO.Put (Label);
          Text_IO.Put (" is ");
          Integer_IO.Put (Value);
          Text_IO.New_Line;
       end;

    begin

       Put (Label => "Foo_1_1", Value => Foo_1_1);
       Put (Label => "Foo_1_2", Value => Foo_1_2);
       Put (Label => "Foo_1_3", Value => Foo_1_3);

       Put (Label => "Foo_2_1", Value => Foo_2_1);
       Put (Label => "Foo_2_2", Value => Foo_2_2);
       Put (Label => "Foo_2_3", Value => Foo_2_3);

    end Test;

    -- End of Test.adb  
-----------------------------------------------------------

And the output:

    -- Begin Output ------

    Foo_1_1 is           0
    Foo_1_2 is           1
    Foo_1_3 is           2
    Foo_2_1 is           0
    Foo_2_2 is           1
    Foo_2_3 is           2

    -- End of Output -----

-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]
Java: Write once, Never revisit

Re: Will "renames" increase program size?

[Dmitry A. Kazakov]

On Sat, 18 Jun 2011 10:58:49 +0200, Yannick Duch�ne (Hibou57) wrote:

> Le Sat, 18 Jun 2011 09:54:29 +0200, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a �crit:
>> Does this copy? It seems that according to you, you cannot tell without
>> looking into the body of Foo:
>>
>>    function Foo return T is -- This copies
>>       Result : T;
>>    begin
>>       return T;
>>    end Foo;
>>
>>    function Foo return T is -- This does not copy
>>    begin
>>       return Result : T;
>>    end Foo;
> 
> May be I did not really understood what you meant, but a simple test  
> program shows this makes no difference:

You have used integer, which is a scalar type. I am not a language layer,
though I guess that the compiler is required to copy in this case. But Adam
meant that for a controlled type it might be illegal to copy from the
return statement.

Here is a test:

with Ada.Finalization;
with Ada.Strings.Unbounded;  use Ada.Strings.Unbounded;
with Ada.Text_IO;            use Ada.Text_IO;

procedure Copying is
   package P is
      type T is new Ada.Finalization.Controlled with record
         Name : Unbounded_String;
      end record;
      overriding procedure Adjust (X : in  out T);
      function Foo_1 (Name : String) return T;
      function Foo_2 (Name : String) return T;
   end P;
   package body P is
      procedure Adjust (X : in  out T) is
      begin
         Put_Line ("Adjust " & To_String (X.Name));
      end Adjust;
      function Foo_1 (Name : String) return T is
         Result : T;
      begin
         Append (Result.Name, Name);
         return Result;
      end Foo_1;
      function Foo_2 (Name : String) return T is
      begin
         return Result : T do
            Append (Result.Name, Name);
         end return;
      end Foo_2;
   end P;
   use P;
   X : T renames Foo_1 ("one way");
   Y : T renames Foo_2 ("another way");
begin
   null;
end Copying;

(My GNAT copies here as well.)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Will "renames" increase program size?

[Yannick Duchêne (Hibou57)]

Le Sat, 18 Jun 2011 12:05:54 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
>
> (My GNAT copies here as well.)
>
For me too, output is

    Adjust one way
    Adjust another way


Adjust is invoked, so there is a copy indeed.

-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]
Java: Write once, Never revisit

Re: Will "renames" increase program size?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:c8ynrt1qxx83.1vaqckntoa8r5$.dlg@40tude.net...
> On Fri, 17 Jun 2011 19:02:49 -0500, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:12lr1j2mmzidu.18gjo4p3e73kk$.dlg@40tude.net...
>>> On Thu, 16 Jun 2011 18:39:35 -0500, Randy Brukardt wrote:
>>>
>>>>>Semantically returning result of a function is always copying because 
>>>>>the
>>>>>object being returned changes the scope.
>>>>
>>>> "Changing scope" doesn't require a copy in either RM or some sort of 
>>>> outside
>>>> logical universe. The only thing that the "scope" of an object controls 
>>>> is
>>>> when it is finalized, and that has nothing to do with the contents 
>>>> (from a
>>>> logical perspective) of the object.
>>>
>>> I fail to see how finalization could have nothing to do with the 
>>> contents.
>>> Finalized objects have no contents, they do not even exist.
>>
>> Sorry, you need the read the RM again. Finalization is a process that
>> happens on objects that exist, and it has no effect on whether they exist 
>> or
>> not. Typically, they cease to exist later (how much later depends on 
>> where
>> they are declared).
>
> Semantically finalized [typed] object does not exist. Object /= memory
> allocated for it.

It does in RM terms. If you want to invent notions other than those in the 
RM, that's fine, but please label them as such. (Then I know I can ignore 
them.)

The most important thing for the definition of a programming language is to 
have a logically complete and consistent definition. It does not matter (at 
least in the abstract) if that definition is the same as you might expect. 
The English meaning of "exist" is much broader than the Ada technical 
meaning, and I couldn't even hazard a guess what meaning might make sense 
for a programming language.

...
>> Last I recall, we were talking about renames, which never copy anything.
>
> Some renames copy, some do not. Consider this example:
>
>   type T is new Ada.Finalization.Controlled ...;
>   function Foo return T;
>
>   X : T renames Foo;
>
> Does this copy?

The renames never copies. We're not talking about what the function call 
might do, that is something completely separate (and irrelevant as to what 
the renames does). A function call might or might not copy its result, and 
the context it calls in does not matter (at least in most implementations).

> It seems that according to you, you cannot tell without
> looking into the body of Foo:
>
>   function Foo return T is -- This copies
>      Result : T;
>   begin
>      return T;
>   end Foo;
>
>   function Foo return T is -- This does not copy
>   begin
>      return Result : T;
>   end Foo;

No, the semantics of both of these return statements is identical.

The truth is that you can *never* tell, and you should never write your code 
so it cares.

> Implementation-dependent semantics is not that good idea.

So you would prefer that Ada is Java, with only one possible set of 
representations for numbers. Because whether or not a compiler supports a 
24-bit integer is implementation-defined, and that is not a good idea...

> In my view any function always copies no matter what. Even when no Adjust
> is called because it happened that the object created for rename shared 
> the
> memory with the function result. Even if it was inlined and optimized away
> completely, semantically, it is still a copy.

Have any view you like, but it has nothing to do with the definition of Ada.

> That Ada's designer possibly thought otherwise, constitutes, in my 
> opinion,
> a language design bug (e.g. bogus limited-valued functions).
>
>> Don't recall any discussion whatsoever about parameter passing. But if
>> parameter passing does in fact do a copy, then there is a semantic effect
>> (on aliasing at the very least).
>
> No, because an attempt to exploit this effect is an error. Semantics does
> not apply to erroneous programs, which is after all, why they are
> erroneous.

Sorry, but "aliasing" is not an error, and does not (usually) make a program 
erroreous). Oh, that's right, you are ignoring the RM definitions of 
everything, so you clearly have this wrong, too. :-)

>> It's pretty hard to do anything in a language definition without there 
>> being
>> a semantic effect. Even when you think there isn't one, clever people 
>> like
>> Adam and Steve Baird will show you one in some convoluted case. (Steve 
>> was
>> just bending my ear about 'Unchecked_Access causing overhead when used to
>> return an object of a local tagged type.)
>
> One might need to generate some code in order to ensure *absence* of any
> semantic effect.
>
> P.S. It seems that you use the word "semantic" as an equivalent to "code"
> (a meaning to the machine). I used it as a meaning to the programmer.

Not at all; I don't know where or why you would think that.

In any case, it doesn't matter; I'm leaving soon for the upcoming meetings, 
and I have to get ready to go, so this discussion is going to stop here. And 
it's obvious that I'm completely wasting my time with you -- you're smart 
and clever enough to be a valuable resource vis-a-vis design and correction 
of the language -- but if you won't even try to use the terminology 
correctly, you're never going to provide any value because I'll never be 
able to tell if you are talking about a real problem or one that exists only 
in your head.

                                        Randy.

Re: Will "renames" increase program size?

[Shark8]

On Jun 18, 5:44 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>
> In any case, it doesn't matter; I'm leaving soon for the upcoming meetings,
> and I have to get ready to go, so this discussion is going to stop here. And
> it's obvious that I'm completely wasting my time with you -- you're smart
> and clever enough to be a valuable resource vis-a-vis design and correction
> of the language -- but if you won't even try to use the terminology
> correctly, you're never going to provide any value because I'll never be
> able to tell if you are talking about a real problem or one that exists only
> in your head.
>
>                                         Randy.

Or the third option: a real problem that you cannot understand because
the words being used to convey the idea are incompatible with the
words that you are using to reconstruct the idea (i.e. someone using
the word 'window' to describe their 'monitor').

Re: Will "renames" increase program size?

[anon]

Yes, it should be bigger during testing.  That is, using debuging, the code 
will include info on both the renamed object as well as the true object.


That is:  
         package TIO renames Ada.Test_IO ;

-- Then using a statements such as 
         TIO.New_Line ;

-- will generate debugging information for 
      TIO.New_Line ;

-- as well as generate information (unrenamed call)
      Ada.Text_IO.New_Line ;

so your object file will be larger as well as you executable file that 
contains debugging information.

But if once you remove all debugging information code. The object and 
executable files will be the same with or without rename statement. 


In <46294109-f07d-49c0-8e81-65a369a05ced@z15g2000prn.googlegroups.com>, Adrian Hoe <abyhoe@gmail.com> writes:
>Hi,
>
>Just out of curiosity, will "renames" increase program size?
>
>e,g,
>
>package A renames Ada.Text_IO;
>
>P : Person_Rec renames Personnel_Record;
>
>I presume Ada compiler will replace the names just like #define in C,
>so no increase in program size. But I just want to be sure.
>
>Thanks.
>--
>Adrian Hoe
>http://adrianhoe.com/adrianhoe