Renaming vs assignment to constant

Renaming vs assignment to constant

[Simon Wright]

A poster on Stack Overflow wrote

   Now : Time renames Clock;

(using Ada.Calendar) which made me blink until I realised that it is the
equivalent of

   Now : constant Time := Clock;

GNAT generates the same code for these two forms. Is there a difference?
Which form is preferred?

Re: Renaming vs assignment to constant

[Jeffrey Carter]

On 12/06/2013 08:14 AM, Simon Wright wrote:
> A poster on Stack Overflow wrote
>
>     Now : Time renames Clock;
>
> (using Ada.Calendar) which made me blink until I realised that it is the
> equivalent of
>
>     Now : constant Time := Clock;
>
> GNAT generates the same code for these two forms. Is there a difference?
> Which form is preferred?

Some people are under the impression that a renaming is more "efficient". I 
prefer that things that are constant be explicitly declared as such.

-- 
Jeff Carter
"I was in love with a beautiful blonde once, dear.
She drove me to drink. That's the one thing I'm
indebted to her for."
Never Give a Sucker an Even Break
109

Re: Renaming vs assignment to constant

[adambeneschan]

On Friday, December 6, 2013 7:14:51 AM UTC-8, Simon Wright wrote:
> A poster on Stack Overflow wrote
> 
>    Now : Time renames Clock;
> 
> (using Ada.Calendar) which made me blink until I realised that it is the
> equivalent of
> 
>    Now : constant Time := Clock;
> 
> GNAT generates the same code for these two forms. Is there a difference?
> 
> Which form is preferred?

I prefer the second form, mostly because in the first one, Time does not "rename" anything the same way that a variable that renames another variable, or a function that renames another function, does.  (Technically, I think Time renames an anonymous object created by the compiler to hold the function result, although it seems like incorrect English to talk about "renaming" something that didn't have a name in the first place.)

However, there *might* be a difference between the two forms if the type involved is (1) a task type or a type that contains a task as a subcomponent, (2) a controlled type or a type that contains one, (3) something with a coextension.  I'm really not sure whether there's a difference in any of these cases, and #2 may be a case where some of the differences are or were dependent on the implementation (because of build-in-place semantics).  I'd have to do some research to figure out if there are any differences.  Maybe Randy already knows the answer.  Also, there may be differences related to accessibility levels.  In this simple case that doesn't involve any of those features, I don't think there's a semantic difference.

                              -- Adam

Re: Renaming vs assignment to constant

[AdaMagica]

For limited types, the constant is impossible.

For function calls, renaming gives the anonymous object a name, the constant is a copy of the anonymous object. But with optimization, the anonymous object may disappear and the constant built in place. So no difference.

For controlled types, there might be a difference (side effects).

Re: Renaming vs assignment to constant

[Eryndlia Mavourneen]

On Friday, December 6, 2013 10:47:03 AM UTC-6, adambe...@gmail.com wrote:
> On Friday, December 6, 2013 7:14:51 AM UTC-8, Simon Wright wrote:
> > A poster on Stack Overflow wrote
> > 
> >    Now : Time renames Clock;
> > 
> > (using Ada.Calendar) which made me blink until I realised that it is the
> > equivalent of
> > 
> >    Now : constant Time := Clock;
> > 
> > GNAT generates the same code for these two forms. Is there a difference?
> > 
> > Which form is preferred?
> 
> I prefer the second form, mostly because in the first one, Time does not "rename" anything the same way that a variable that renames another variable, or a function that renames another function, does.  (Technically, I think Time renames an anonymous object created by the compiler to hold the function result, although it seems like incorrect English to talk about "renaming" something that didn't have a name in the first place.)
> 
> However, there *might* be a difference between the two forms if the type involved is (1) a task type or a type that contains a task as a subcomponent, (2) a controlled type or a type that contains one, (3) something with a coextension.  I'm really not sure whether there's a difference in any of these cases, and #2 may be a case where some of the differences are or were dependent on the implementation (because of build-in-place semantics).  I'd have to do some research to figure out if there are any differences.  Maybe Randy already knows the answer.  Also, there may be differences related to accessibility levels.  In this simple case that doesn't involve any of those features, I don't think there's a semantic difference.
> 
>                               -- Adam

I believe "rename" is just that -- creating another name for an entity.  There may be a difference in scope of the new name (possibly more limited), but it seems that there should not be any other differences.  Kind of like a sophisticated version of #define that is syntax- and semantic-smart.

-- Eryndlia Mavourneen (KK1T)

Re: Renaming vs assignment to constant

[Jeffrey Carter]

On 12/06/2013 11:03 AM, AdaMagica wrote:
> For limited types, the constant is impossible.

This was true in Ada-95 and earlier, but not in more recent versions. Indeed, I 
suspect that renaming a function result was introduced to make such limited 
constants possible.

-- 
Jeff Carter
"I was in love with a beautiful blonde once, dear.
She drove me to drink. That's the one thing I'm
indebted to her for."
Never Give a Sucker an Even Break
109

Re: Renaming vs assignment to constant

[G.B.]

On 06.12.13 16:14, Simon Wright wrote:
> A poster on Stack Overflow wrote
>
>     Now : Time renames Clock;
>
> (using Ada.Calendar) which made me blink until I realised that it is the
> equivalent of
>
>     Now : constant Time := Clock;
>
> GNAT generates the same code for these two forms. Is there a difference?
> Which form is preferred?


Generated code is (or was) more efficient for arrays because the array
object renamed isn't (or wasn't) copied into the constant.

FTR, with limited types returned by reference (Ada 95),
a difference between renaming and a constant declaration is
that the former is possible.

       type Id is range 1 .. 3;
       type LT is limited private;

       function Choose (Choice : Id) return LT;


       X : LT renames Choose (2);

       Some_Op (Choose (1));


Today, returning an *existing* limited object requires the
use of a pointer, IINM.

Re: Renaming vs assignment to constant

[adambeneschan]

On Friday, December 6, 2013 10:35:12 AM UTC-8, G.B. wrote:

> Generated code is (or was) more efficient for arrays because the array 
> object renamed isn't (or wasn't) copied into the constant.

Definitely not necessarily true for Ada 2012; 7.6(17.1-17.4) specify that the object may be built in place, without an copying.  Build-in-place is required for some types, and allowed for all others.  For the cases where it's not required, renaming could be more efficient depending on the compiler implementation.

Prior to Ada 2012, I don't think this was necessarily true either, where no controlled types are involved.  The language semantics do say that a function result is stored in an anonymous object, and then the constant is created and the anonymous object assigned into it.  But the language semantics only tell you what effect a program is supposed to have, not what the generated instructions are supposed to look like.  So if a copy is a straight block copy that would do nothing but waste time, nothing in the RM requires the program to have instructions that put the data in a different place and then copy it.  (There may be an obscure case where it would make a difference, i.e. if the object being built has a "for Obj'Address use..." clause and the function has an extended return and an exception is raised during the extended return.)  But when controlled types are involved, there were cases where a rename would be more efficient, prior to Ada 2012.

                                -- Adam

Re: Renaming vs assignment to constant

[Shark8]

On Friday, December 6, 2013 8:14:51 AM UTC-7, Simon Wright wrote:
> A poster on Stack Overflow wrote
> 
>    Now : Time renames Clock;

That was me! :)


> (using Ada.Calendar) which made me blink until I realised that it is the
> equivalent of
> 
>    Now : constant Time := Clock;

Yep, it is. I probably used it because I had recently run into a C# problem where renaming a variable [and typecast] would have been *VERY* useful.

'Renames' doesn't get enough love; its been neglected over the past [few] standard revisions. -- After using some of the Ada1012 features it'd be kinda nice to put pre/post conditions on a callback independent of those of the actual subprogram referenced; perhaps:

type callback_type is not null access procedure;
Procedure Some_Procedure;
--...
 callback : callback_type renames procedure'access
               with pre => [...], post => [...];

Generics are another feature that seems to have been neglected (for 2005 and 2012), even though they're really pretty good in Ada they could be better still... perhaps a bit of polishing such as allowing Instantiation.Input_variable on formal parameter Input_Variable (conceptually IN would map to constant, IN OUT to a variable, and OUT should likely be handled as an out parameter in a subprogram): this would allow for clients of an instantiation to depend on it w/o having to be generics themselves.

> GNAT generates the same code for these two forms. Is there a difference?
> Which form is preferred?

I think the big difference happens when the result has subcomponents:
    ch   : constant Character:= 'X';             -- Character X.
    temp : String  renames Character'Image(ch);  -- Its image: 'X'.
    ch2  : Character renames temp(2);            -- The unquoted character.

Re: Renaming vs assignment to constant

[adambeneschan]

On Friday, December 6, 2013 1:59:21 PM UTC-8, Shark8 wrote:

> I think the big difference happens when the result has subcomponents:
>     ch   : constant Character:= 'X';             -- Character X.
>     temp : String  renames Character'Image(ch);  -- Its image: 'X'.
>     ch2  : Character renames temp(2);            -- The unquoted character.

What is the big difference between that and
     
    ch   : constant Character:= 'X';                -- Character X.
    temp : constant String := Character'Image(ch);  -- Its image: 'X'.
    ch2  : Character renames temp(2);               -- The unquoted character.

???  Maybe I'm having a bad day, but I don't see it.

                               -- Adam

Re: Renaming vs assignment to constant

[Randy Brukardt]

<adambeneschan@gmail.com> wrote in message 
news:c95e7c9c-6c3b-472b-ac5e-d70538bfc41a@googlegroups.com...
On Friday, December 6, 2013 7:14:51 AM UTC-8, Simon Wright wrote:
>> A poster on Stack Overflow wrote
>>
>>    Now : Time renames Clock;
>>
>> (using Ada.Calendar) which made me blink until I realised that it is the
>> equivalent of
>>
>>    Now : constant Time := Clock;
>>
>> GNAT generates the same code for these two forms. Is there a difference?
>>
>> Which form is preferred?
>
>I prefer the second form, mostly because in the first one, Time does not 
>"rename" anything the
>same way that a variable that renames another variable, or a function that 
>renames another
>function, does.  (Technically, I think Time renames an anonymous object 
>created by the compiler
>to hold the function result, although it seems like incorrect English to 
>talk about "renaming"
>something that didn't have a name in the first place.)

Be glad that we didn't introduce named anonymous access types. :-) [We 
seriously considered that, to allow named types with dynamic accessibility 
and the special anonymous access-to-subprogram rules, but decided it was 
just too weird.]

>However, there *might* be a difference between the two forms if the type 
>involved is (1) a task type
>or a type that contains a task as a subcomponent, (2) a controlled type or 
>a type that contains one,
>(3) something with a coextension.  I'm really not sure whether there's a 
>difference in any of these
>cases, and #2 may be a case where some of the differences are or were 
>dependent on the
>implementation (because of build-in-place semantics).  I'd have to do some 
>research to figure
>out if there are any differences.  Maybe Randy already knows the answer. 
>Also, there may be
>differences related to accessibility levels.  In this simple case that 
>doesn't involve any of those
>features, I don't think there's a semantic difference.

Any differences in (1) and (2) would be because there is a difference in 
accessibility levels. I think there is such a difference, but you're not 
going to talk me into a trip into the Heart-of-Darkness (3.10.2) to figure 
it out!

In general, the difference between:

   R : <something> renames <name>;

and

  C : constant <something> := <name>;

is that the former is essentially by reference (and any constraints on 
<something> are ignored, a terrible Ada 83 decision made mainly because they 
didn't want to introduce a complex concept like static matching -- which of 
course the Ada 95 team decided had to be introduced, so there are no 
language complexity savings and a lot of confusion over the meaning) and the 
latter is essentially by-copy (a copy of <name> is made).

For the function call case, the thing being renamed is an anonymous return 
object, so the difference isn't really noticable, especially with the 
various permissions and requirements to eliminate those objects.

                             Randy.

Re: Renaming vs assignment to constant

[Shark8]

On Friday, December 6, 2013 4:48:41 PM UTC-7, adambe...@gmail.com wrote:
> 
> > I think the big difference happens when the result has subcomponents:
> >     ch   : constant Character:= 'X';             -- Character X.
> >     temp : String  renames Character'Image(ch);  -- Its image: 'X'.
> >     ch2  : Character renames temp(2);            -- The unquoted character.

Size of Ch:    Assuming 8.
Size of temp:  24 + Bounds(assuming 64).
Size of Ch2:   None, it's a reference-to/alias-of Temp(2).

Total 96 bits.

> What is the big difference between that and
>     ch   : constant Character:= 'X';                -- Character X.
>     temp : constant String := Character'Image(ch);  -- Its image: 'X'.
>     ch2  : constant Character := temp(2);           -- The unquoted character.

Size of Ch:    Assuming 8.
Size of temp:  24 + Bounds(assuming 64).
Size of Ch:    Assuming 8.

Total 104 bits.


Obviously this will really only make a real difference performance-wise when the renamed object's type is large, but there're other reasons to use renames, like component selection of deeply composed objects... but that's a different topic.

Re: Renaming vs assignment to constant

[adambeneschan]

On Friday, December 6, 2013 5:04:18 PM UTC-8, Shark8 wrote:
> On Friday, December 6, 2013 4:48:41 PM UTC-7, adambe...@gmail.com wrote:
> 
> > 
> 
> > > I think the big difference happens when the result has subcomponents:
> 
> > >     ch   : constant Character:= 'X';             -- Character X.
> > >     temp : String  renames Character'Image(ch);  -- Its image: 'X'.
> > >     ch2  : Character renames temp(2);            -- The unquoted character.
> 
> Size of Ch:    Assuming 8.
> Size of temp:  24 + Bounds(assuming 64).
> Size of Ch2:   None, it's a reference-to/alias-of Temp(2).
> 
> Total 96 bits.
> 
> 
> > What is the big difference between that and
> >     ch   : constant Character:= 'X';                -- Character X.
> >     temp : constant String := Character'Image(ch);  -- Its image: 'X'.
> >     ch2  : constant Character := temp(2);           -- The unquoted character.

Ummm, no, you changed it.  I kept the "renames" in the declaration of ch2; I only changed the declaration of "temp" from your earlier post.  Since this thread is about the difference is declaring an object that renames a function result, and declaring a constant object that's assigned to a function result, I think discussing a rename of a subcomponent is off-topic for this thread.

                               -- Adam

Re: Renaming vs assignment to constant

[Shark8]

On Friday, December 6, 2013 5:47:37 PM UTC-7, Randy Brukardt wrote:
> <adambeneschan> wrote in message 
> 
> >(Technically, I think Time renames an anonymous object 
> >created by the compiler
> >to hold the function result, although it seems like incorrect English to 
> >talk about "renaming"
> >something that didn't have a name in the first place.)
> 
> Be glad that we didn't introduce named anonymous access types. :-) [We 
> seriously considered that, to allow named types with dynamic accessibility 
> and the special anonymous access-to-subprogram rules, but decided it was 
> just too weird.]

That could actually be quite useful in very specific cases; especially since only anonymous access types can be used in discriminants to parametrize [types] on non-scalar values.

But it would likely make accessibility checks worse for that little increase in functionality.

Re: Renaming vs assignment to constant

[J-P. Rosen]

Le 07/12/2013 02:04, Shark8 a écrit :
>> What is the big difference between that and
>> >     ch   : constant Character:= 'X';                -- Character X.
>> >     temp : constant String := Character'Image(ch);  -- Its image: 'X'.
>> >     ch2  : constant Character := temp(2);           -- The unquoted character.
> Size of Ch:    Assuming 8.
> Size of temp:  24 + Bounds(assuming 64).
> Size of Ch:    Assuming 8.
> 
> Total 104 bits.
But you don't need temp:
 ch  : constant Character:= 'X';                  -- Character X.
 ch2 : constant String := Character'Image(ch)(2); -- 'X' unquoted



-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Renaming vs assignment to constant

[J-P. Rosen]

Le 07/12/2013 07:17, J-P. Rosen a écrit :
>  ch2 : constant String := Character'Image(ch)(2); -- 'X' unquoted
                  ^^^^^^ Character of course

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Renaming vs assignment to constant

[Dmitry A. Kazakov]

On Fri, 6 Dec 2013 13:59:21 -0800 (PST), Shark8 wrote:

> After using some of the Ada1012 features it'd be kinda nice to put
> pre/post conditions on a callback independent of those of the actual
> subprogram referenced; perhaps:

Renaming was always infamous for ignoring whatever constraints:

   type A is array (Integer range <>) of Float;
   procedure Foo (X : in out A) is
      subtype Slided is A (10..20);
      Y : Slided renames X (X'First..X'First + 9);
   begin
      X (10) := 0.0; -- Not what you would think!
   end Foo;

So it would not work unless renaming fixed first. Neither would happen.

Then, the very idea of putting constraints on individual objects is just
wrong because untyped and fragile design. Constraint should be a property
of a type if a part of the contract. Instances should have no contracts of
their own.

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

Re: Renaming vs assignment to constant

[Dmitry A. Kazakov]

On Sat, 7 Dec 2013 09:57:27 +0100, Dmitry A. Kazakov wrote:

> On Fri, 6 Dec 2013 13:59:21 -0800 (PST), Shark8 wrote:
> 
>> After using some of the Ada1012 features it'd be kinda nice to put
>> pre/post conditions on a callback independent of those of the actual
>> subprogram referenced; perhaps:
> 
> Renaming was always infamous for ignoring whatever constraints:
> 
>    type A is array (Integer range <>) of Float;
>    procedure Foo (X : in out A) is
>       subtype Slided is A (10..20);
>       Y : Slided renames X (X'First..X'First + 9);
>    begin
>       X (10) := 0.0; -- Not what you would think!
^^^^^
   Y (10) := 0.0;

of course.

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