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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,63ed09fc54092c73 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.66.84.136 with SMTP id z8mr1621622pay.2.1359739962949; Fri, 01 Feb 2013 09:32:42 -0800 (PST) X-Received: by 10.50.34.167 with SMTP id a7mr248817igj.5.1359739962905; Fri, 01 Feb 2013 09:32:42 -0800 (PST) Path: 6ni27960pbd.1!nntp.google.com!ld4no12858241pbb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 1 Feb 2013 09:32:42 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ NNTP-Posting-Host: 66.126.103.122 References: <6d66d1c4-ed22-446b-a9d7-dc806ae1ef8f@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <5ab43474-0ce2-425c-836b-ff4c97587958@googlegroups.com> Subject: Re: When is a rename not a rename? From: Adam Beneschan Injection-Date: Fri, 01 Feb 2013 17:32:42 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2013-02-01T09:32:42-08:00 List-Id: On Friday, February 1, 2013 3:27:02 AM UTC-8, Dmitry A. Kazakov wrote: > On Fri, 1 Feb 2013 02:44:21 -0800 (PST), Ada novice wrote: >=20 > > If you have a minimal example that is proving the contrary, please post= it here. >=20 > Here is how renaming is not renaming: These examples aren't close to what I was getting at. I was trying to talk= about cases where Y renames X; but if you replace X in your program with Y= , and both programs are legal, the program runs differently. (Not counting= cases where changing X to Y causes changes in the meanings of other identi= fiers later in the program because of the visibility rules.) Your first two examples are cases where you can't use a rename because of t= he language rules, so these are definitely not the same thing. In the firs= t case, you just don't like how the scoping rules apply to exception handle= rs--it has nothing to do with renaming. The second case is one that probab= ly could be fixed by language rules, although I doubt it will happen. It's= mildly annoying that an ambiguous identifier error can be triggered by two= identifiers with the same name that rename the same entity. The third cas= e is the opposite of what I'm talking about: if you replace X :=3D -1 with = Y :=3D -1 the program has the exact same behavior. It may be annoying that= the rename allows you to put an additional constraint on the renaming vari= able and then ignores it. I agree that it may have been a mistake to allow= this. But it's still not the same thing I was discussing. Here's an example that may answer YC's question: package Pack1 is pragma Elaborate_Body; end Pack1; with Ada.Text_IO; package body Pack1 is begin Text_IO.Put_Line ("Pack1 is elaborated"); end Pack1; package Pack2 is end Pack2; with Pack1, Pack2; package Pack3 renames Pack2; with Pack2; -- with Pack3; <=3D=3D=3D HERE procedure Test is begin null; end Test; If you run Test, nothing happens; but if you change the HERE line to "with = Pack3;", then when you run Test, it outputs "Pack1 is elaborated", even tho= ugh Pack3 renames Pack2. That's what I was talking about. Pack3 is not a = strict "rename" in the sense that I understand the term (and apparently Ran= dy likes to think of it as a wrapper of sorts rather than a strict rename). Another possible example is when a subprogram renames another one but chang= es a default parameter: procedure P1 (N1 : Integer; N2 : Integer :=3D 0) is ... procedure P2 (N1 : Integer; N2 : Integer :=3D 1) renames P1; P1(5); P2(5); Another case where P2 renames P1, but changing P1 to P2 has a different eff= ect. I think this capability was allowed deliberately, though, with the ex= pectation that it might be useful. Probably, if you do something like this= , you should put comments on P2 to make it clear that this isn't a strict r= ename---and similarly on Pack3 in my earlier example. -- Adam