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.180.98.103 with SMTP id eh7mr955283wib.3.1359505718598; Tue, 29 Jan 2013 16:28:38 -0800 (PST) MIME-Version: 1.0 X-FeedAbuse: http://nntpfeed.proxad.net/abuse.pl feeded by 78.192.65.63 Path: i11ni28052wiw.0!nntp.google.com!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!nntpfeed.proxad.net!news.muarf.org!news.ecp.fr!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: When is a rename not a rename? Date: Tue, 29 Jan 2013 18:28:29 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <6d66d1c4-ed22-446b-a9d7-dc806ae1ef8f@googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1359505716 26030 69.95.181.76 (30 Jan 2013 00:28:36 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 30 Jan 2013 00:28:36 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Date: 2013-01-29T18:28:29-06:00 List-Id: What else could it mean? We don't want to be ignoring "with" clauses in one rarely used case, so it has to cause a semantic dependence here. And this doesn't have anything to do with the rename per-se; this is a compilation unit like any other (that happens to be a rename), and it is the compilation unit that has this effect, not the rename. I always think of all compilation units as packages (imagining an invisible package wrapping anything that isn't a normal package), and when you do that, this makes plenty of sense. Randy. "Adam Beneschan" wrote in message news:6d66d1c4-ed22-446b-a9d7-dc806ae1ef8f@googlegroups.com... I've always assumed that if you declare a name to be a rename of some other entity (*), there wouldn't be any impact on the program, other than that you can use the new name to mean the same thing as the thing that it renames. In particular, for library unit packages, if P2 is a library unit package that renames P1, then a unit that says "with P2;" should work the same as one that says "with P1;" after you've done whatever is necessary to make sure all names in the unit refer to the same entities. Right? I've just discovered that this isn't the case... with P1; with P3; package P2 renames P1; Now, a program that says "with P2;" may operate differently from one that with's P1--because saying "with P2" will cause P3's elaboration code to be executed at the beginning of the program, while saying "with P1" will not [unless P3 is included in the program via some other path]. I wonder if this was the intent, or if it's a "bug" in the language definition? -- Adam (*) Not counting a renaming-as-body, which is different because the first declaration of the name is *not* a renaming declaration.