Re: When is a rename not a rename?

["Randy Brukardt" <randy@rrsoftware.com>]

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" <adam@irvine.com> 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.