Re: Will "renames" increase program size?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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