RENAMES?

RENAMES?

[joes]

Are renames tied to the value of the renamed variable at the time that
they are elaborated, or do they always maintain the value of the renamed
variable?

I have an example program and I can't decide what it is supposed to
do. Can anyone help?

Thanks.

				Joe Schwartz
				Harris Corp.

				joes@HARRIS.COM

------------------------------------ cut here ----------------------------------

procedure rename is

 type ptr_type is access integer;
 acc : ptr_type := new integer'(1);
 ren_var : integer renames acc.all;     -- ren_var now equals 1

begin
       acc := new integer'(10);         -- change its value behind it's back

-- WHAT IS ren_var's VALUE AT THIS POINT? 1 or 10?

end rename;

------------------------------------------------------------------------------

Re: RENAMES?

[brucej]

RM 8.5(3): "The elaboration of a renaming declaration evaluates the
name that follows the reserved word _renames_ and thereby determines the
entity denoted by this name (the renamed entity)."

The RM makes it pretty clear that the value of the renamed object
should be frozen at elaboration time, and that you should not expect
to be able to change it's value "behind the rename's back".

So the value of `ren_var' is 1.

Re: RENAMES?

[Arny B. Engelson]

In article <94700003@hcx1>, brucej@hcx1.SSD.HARRIS.COM writes:
> 
> RM 8.5(3): "The elaboration of a renaming declaration evaluates the
> name that follows the reserved word _renames_ and thereby determines the
> entity denoted by this name (the renamed entity)."
> 
> The RM makes it pretty clear that the value of the renamed object
> should be frozen at elaboration time, and that you should not expect
> to be able to change it's value "behind the rename's back".
> 
> So the value of `ren_var' is 1.

I'd like to add one point that may not be clear to all:
The value of the new object can be changed by referencing the original
object.  Referencing the original example:

   replacing:      acc := new integer'(10);
   with:           acc.all := 10;

   would change the value of ren_var to 10 because ren_var and acc.all denote
   the same entity.


Arny B. Engelson    {ihnp4|bonnie|clyde}!wayback!arny

Re: RENAMES?

[Scott Killian]

> S nucsrl:comp.lang.ada / joes@hcx2.SSD.HARRIS.COM / 10:26 am  Aug 17, 1987 /
> Are renames tied to the value of the renamed variable at the time that
> they are elaborated, or do they always maintain the value of the renamed
> variable?
> 
> [ etc ]
> 
> -- WHAT IS ren_var's VALUE AT THIS POINT? 1 or 10?
>
>> / nucsrl:comp.lang.ada / brucej@hcx1.SSD.HARRIS.COM /  3:02 pm  Aug 17, 1987 /
>>The RM makes it pretty clear that the value of the renamed object
>>should be frozen at elaboration time, and that you should not expect
>>to be able to change it's value "behind the rename's back".
>

The entity, not the value, is frozen at elaboration time.

When a "renames" is used for an object, both *names* now refer to the
same *entity*.  A renaming declaration is like aliasing, as a form of
shorthand, or to resolve name conflicts (see RM 8.5, under "Notes:")

RM Appendix D (Glossary) states:  "Renaming declaration:  A renaming
declaration declares another name for an entity."

The following example is given in RM 8.5:

	declare
	    L : PERSON renames LEFTMOST_PERSON;
			-- see 3.8.1 [LEFTMOST_PERSON is a record type -- swk]
	begin
	    L.AGE := L.AGE + 1;
	end;

In this example, the "shorthand alias" is used to change the value
entity to which it refers.  Changes made to "L" affect
"LEFTMOST_PERSON" and v.v.:  they both denote the same entity.

If the renaming only used the value existing when elaborated, then the
declaration
	a : integer := 10;
	b : integer renames a;
would be equivalent to
	a : integer := 10;
	b : constant integer := a;
which would be maintaining *two* entities, with the second initialized
to the value of the first.  The RM does not suggest this interpretation.

The following example program was run under the Verdix Ada Development
System 5.41 (4.3 BSD):

	with integer_io; use integer_io;
	with text_io; use text_io;
	procedure rename is
	    type ptr is access integer;
	    i_ptr : ptr := new integer'(1);
	    val : integer renames i_ptr.all;
	begin
	    put(val);			-- original
-- case 1
	    i_ptr.all := 5;
	    put(val);			-- after changing the entity's value
 -- case 2
	    i_ptr := new integer'(10);
	    put(val); 			-- after allocating new entity
	    new_line;
	end rename;

This program has the following output:
	1	5	5


Hmm.  It looks like in one place the renamed thing is affected, yet in
the other place, it is not.

This is because at elaboration time, the new name is bound not to the
current *value* of the entity, but to the current *entity*.

In case 1, the entity referenced by 'i_ptr.all' is the same as that
referenced by 'val', which happens to be a dynamically allocated
integer with value 1.  The value of that integer is then changed to 5,
so 'val' evaluates to 5 also.

In case 2, 'i_ptr' is changed, and 'i_ptr.all' now references a *new*
entity, namely a new dynamically allocated integer with value 10 (which
now has nothing to do with the current value of 'val').

Now, 'val' refers to the first entity (which still exists, since it was
never deallocated), and 'i_ptr.all' refers to the new entity.

> -- WHAT IS ren_var's VALUE AT THIS POINT? 1 or 10?

1

	Scott


		Scott Killian
		Northwestern University
		internet:  killian@eecs.nwu.edu
		uucp:      {gargoyle, chinet, ihnp4}!nucsrl!killian