From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!husc6!sri-unix!sri-spam!mordor!lll-tis!lll-lcc!ptsfa!ihnp4!chinet!nucsrl!killian
From: killian@nucsrl.UUCP (Scott Killian)
Newsgroups: comp.lang.ada
Subject: Re: RENAMES?
Message-ID: <3930017@nucsrl.UUCP>
Date: Wed, 19-Aug-87 18:47:58 EDT
Article-I.D.: nucsrl.3930017
Posted: Wed Aug 19 18:47:58 1987
Date-Received: Sat, 22-Aug-87 19:59:55 EDT
References: <94700001@hcx2>
Organization: Northwestern U, Evanston IL, USA
List-Id: <comp.lang.ada>


> 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