Re: Will "renames" increase program size?

["Randy Brukardt" <randy@rrsoftware.com>]

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