Common ancestor (visibility rules)

Common ancestor (visibility rules)

[dmitry6243]

Hello!

Perhaps I've missed something, but it seems that compilation units
(except for library ones) do not have common ancestor. Here is a simple
example to highlight the problem:
------------------- a.ads
package A is
   procedure Foo;
end A;
------------------- b.ads
package B is
   procedure A;
end B;
------------------- b.adb
package body B is
   procedure A is separate;
end B;
------------------- b-a.adb
with A;
separate (B)
procedure A is
begin
   A.Foo; -- Error!
end A;

Now there is no way to use A.Foo in B.A, because B.A hides A. The
problem could be easily solved if all compilation unit had have a common
ancestor package, say "Root". Then package A could be specified as
Root.A and A's Foo as Root.A.Foo. Interesting is that C++ has this
feature.

Regards,
Dmitry Kazakov


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Common ancestor (visibility rules)

[Robert Dewar]

In article <8bprin$a37$1@nnrp1.deja.com>,
  dmitry6243@my-deja.com wrote:
> Hello!
>
> Perhaps I've missed something

yup!

> but it seems that compilation units
> (except for library ones) do not have common ancestor.

of course they do, it is called standard, all library packages
are compiled within standard.


>    A.Foo; -- Error!

no exclamation mark needed, obviously A is not visible here!

> Now there is no way to use A.Foo in B.A, because B.A hides A.
The
> problem could be easily solved if all compilation unit had
have a common
> ancestor package, say "Root".

No need to invent a new name, it is called Standard


 Then package A could be specified as
> Root.A and A's Foo as Root.A.Foo.

Try Standard.A.Foo

> Interesting is that C++ has this
> feature.

Perhaps they copied it from Ada 95 :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Common ancestor (visibility rules)

[Steve Folly]

On Tue, 28 Mar 2000 08:47:22 GMT, dmitry6243@my-deja.com did clatter that
keyboard and type:

>Hello!
>
>Perhaps I've missed something, but it seems that compilation units
>(except for library ones) do not have common ancestor. Here is a simple
>example to highlight the problem:
>------------------- a.ads
>package A is
>   procedure Foo;
>end A;
>------------------- b.ads
>package B is
>   procedure A;
>end B;
>------------------- b.adb
>package body B is
>   procedure A is separate;
>end B;
>------------------- b-a.adb
>with A;
>separate (B)
>procedure A is
>begin
>   A.Foo; -- Error!
>end A;
>
>Now there is no way to use A.Foo in B.A, because B.A hides A. The
>problem could be easily solved if all compilation unit had have a common
>ancestor package, say "Root". Then package A could be specified as
>Root.A and A's Foo as Root.A.Foo. Interesting is that C++ has this
>feature.
>

Well, the Ada95 team beat you to it, 10.1.1(1) of the LRM states:

"A library_item is a compilation unit that is the declaration, body, or renaming
of a library unit. Each library unit (except Standard) has a parent unit, which
is a library package or generic library package. A library unit is a child of
its parent unit. The root library units are the children of the predefined
library package Standard. "

Which, in layman's terms means any specific non-child package is implicitly a
child of package Standard.

So to get your separate A procedure to compile you need to fully qualify
A.Foo as Standard.A.Foo.


Hope that helps.
Steve Folly.

Re: Common ancestor (visibility rules)

[dmitry6243]

In article <8bq726$lo8$1@nnrp1.deja.com>,
Robert Dewar <robert_dewar@my-deja.com> wrote:

> No need to invent a new name, it is called Standard
>
> Then package A could be specified as
> > Root.A and A's Foo as Root.A.Foo.

Yes, "Standard" was actually my first attempt, but I tried the
following (of course in the real program):
-------------------- b-a.adb
with Standard.A; use Standard.A;
separate (B)
procedure A is
begin
   Foo;
end A;

which does not work, because compiler do not understand withing of
Standard.A. This caused my confusion. The correct version is:
-------------------- b-a.adb
with A; use Standard.A;
separate (B)
procedure A is
begin
   Foo;
end A;

I must say, that the difference is rather subtle. I suppose it has some
relation with unit library management. Perhaps compiler should first
search for physical childs of Standard and then in case of failure,
discard the "Standard" prefix, so that:

with Standard.A; use Standard.A;

would be correct?

> > Interesting is that C++ has this
> > feature.
>
> Perhaps they copied it from Ada 95 :-)

Surely they did! (:-))

Regards,
Dmitry Kazakov


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Common ancestor (visibility rules)

[Robert Dewar]

In article <8bsgpf$96f$1@nnrp1.deja.com>,
  dmitry6243@my-deja.com wrote:

> In article <8bq726$lo8$1@nnrp1.deja.com>,
> Robert Dewar <robert_dewar@my-deja.com> wrote:
>
> > No need to invent a new name, it is called Standard
> >
> > Then package A could be specified as
> > > Root.A and A's Foo as Root.A.Foo.
>
> Yes, "Standard" was actually my first attempt,

Well you have got yourself quite confused here. There are two
ways of doing things. You either use a USE statement, or you
qualify the name. Your original post was about the second
attempt, and the proper form is simply

   Standard.A.Foo;

Now if you want to use a USE statement, you have a much simpler
form for a-b.adb:

   with A; use A;
   separate (B)
   procedure A is
   begin
      Foo;
   end A;

and that of course is perfectly fine, since the "use A" makes
Foo visible.

> but I tried the following

> with Standard.A; use Standard.A;

No, that's completely wrong, why, because you can only WITH
a library unit, and Standard is NOT a library unit, it is the
ancestor of all library units, a library unit is PRECISELY
something which is a *child* of standard, and standard is
definitely not its own child!

> The correct version is:
> -------------------- b-a.adb
> with A; use Standard.A;

No, that is not the correct version (though it is legal).
The Standard. prefix here is odd and completely unnecessary
in all circumstances in a use clause.

> I must say, that the difference is rather subtle.

Not subtle at all once you have the right model, which is
that there is Standard at the outer level, and then all the
library units are children of Standard.

> Perhaps compiler should first
> search for physical childs of Standard and then in case of
> failure, discard the "Standard" prefix, so that:
>
> with Standard.A; use Standard.A;
>
> would be correct?

No, that would

a) be a very confusing rule once you understand things

b) be totally unnecessary, since you can always write
   this as:

       with A; use A;

   which is the obvious convenient and useful way to write this.

c) would cause confusion and ambiguity as further explored
   below.

The only time you need an explicit prefix of Standard is when
you are trying to reference an outer entity of the same name
as an inner entity by explicit qualification. In fact this
very rarely happens, why? because it is generally very bad
style to reuse names this way. In your little example, you
are operating in an environment where the code knows that
A is a library unit, and intends to use a procedure from
A. It is not illegal, but it *is* bad practice and confusing
to use this same name A for one of your procedures in this
region.

By the way, it is under some circumstances legal (though very
bad practice to write)

   with Standard.A;

If you really understand things by now, you should be able to
figure out the conditions.

We can only *with* a library unit, so the above is legal only
if there is a library unit Standard and a child Standard.A.

Well we learned from above that the Standard that is in the RM
is NOT a library unit, but rather the parent of all library
units, so the above must imply that there is another Standard
that is a library unit.

A bit surprisingly, this is allowed, there is nothing illegal
about writing a library package of your own:

   package Standard is ...

and a child of it

   package Standard.A is ...

Now this is simply horrible practice, it would be as bad, or
perhaps worse than writing

   package Integer is ...

which is also legal but horrible.

If you absolutely MUST write a package called Standard, and
then you need to reference an entity within this package in
a situation where there is am ambiguity similar to your
original:

   with Standard;
   package body Foo is
      procedure Standard is
      begin
         Standard.Junk; -- call Junk from Standard package
      end;
   end;

then to deal with the fact that you have hidden the standard
you want with the local procedure Standard, you could either
use a use clause:

   with Standard; use Standard;

or you could fully qualify:

        Standard.Standard.Junk;

Of course this is perfectly frightful code, due to the
atrocious bad choice of Standard in your own code, but it
is legal, and should help explain why your suggestion of
some special casing for "with Standard" would not work :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Common ancestor (visibility rules)

[dmitry6243]

In article <8bskgp$ctu$1@nnrp1.deja.com>,
Robert Dewar <dewar@gnat.com> wrote:

> In article <8bsgpf$96f$1@nnrp1.deja.com>,
> dmitry6243@my-deja.com wrote:
>
> > In article <8bq726$lo8$1@nnrp1.deja.com>,
> > Robert Dewar <robert_dewar@my-deja.com> wrote:
> >
> > > No need to invent a new name, it is called Standard
> > >
> > > Then package A could be specified as
> > > > Root.A and A's Foo as Root.A.Foo.
> >
> > Yes, "Standard" was actually my first attempt,
>
> Well you have got yourself quite confused here. There are two
> ways of doing things. You either use a USE statement, or you
> qualify the name. Your original post was about the second
> attempt, and the proper form is simply
>
> Standard.A.Foo;
>
> Now if you want to use a USE statement, you have a much simpler
> form for a-b.adb:
>
> with A; use A;
> separate (B)
> procedure A is
> begin
>    Foo;
> end A;

I must give a bit more backgroud of what I am doing. I am trying to make
the code compiled by both Aonix and GNAT. So, the result is

with A; use A;           -- OK with Aonix, error in GNAT (v3.12)
with A; use Standard.A;  -- Error in Aonix, OK with GNAT

Therefore my question, what is correct.

> and that of course is perfectly fine, since the "use A" makes
> Foo visible.
>
> > but I tried the following
>
> > with Standard.A; use Standard.A;
>
> No, that's completely wrong, why, because you can only WITH
> a library unit, and Standard is NOT a library unit, it is the
> ancestor of all library units, a library unit is PRECISELY
> something which is a *child* of standard, and standard is
> definitely not its own child!

I.e. Standard is a unit, but not a library unit. Then there seems to be
two arts of unit names: library names starting with Standard that can be
*used* but not *withed*, then "un-library" names without Standard
prefix. They can be *withed* and sometimes *used*. Right?

> > The correct version is:
> > -------------------- b-a.adb
> > with A; use Standard.A;
>
> No, that is not the correct version (though it is legal).
> The Standard. prefix here is odd and completely unnecessary
> in all circumstances in a use clause.

It is works in GNAT and illegal in Aonix, but see above.

> > I must say, that the difference is rather subtle.
>
> Not subtle at all once you have the right model, which is
> that there is Standard at the outer level, and then all the
> library units are children of Standard.
>
> > Perhaps compiler should first
> > search for physical childs of Standard and then in case of
> > failure, discard the "Standard" prefix, so that:
> >
> > with Standard.A; use Standard.A;
> >
> > would be correct?
>
> No, that would
>
> a) be a very confusing rule once you understand things

I am afraid "with A; use Standard.A;" is much more confusing.

> b) be totally unnecessary, since you can always write
> this as:
>
> with A; use A;
>
> which is the obvious convenient and useful way to write this.

So GNAT is wrong?

> c) would cause confusion and ambiguity as further explored
> below.

I do not see how. Either Standard.A is the name of A or not. If yes then
why "with Standard.A;" is illegal. If not, why "use Standard.A;" is
legal.

> The only time you need an explicit prefix of Standard is when
> you are trying to reference an outer entity of the same name
> as an inner entity by explicit qualification. In fact this
> very rarely happens, why? because it is generally very bad
> style to reuse names this way. In your little example, you
> are operating in an environment where the code knows that
> A is a library unit, and intends to use a procedure from
> A. It is not illegal, but it *is* bad practice and confusing
> to use this same name A for one of your procedures in this
> region.

It is disputable. The original program has two packages: Lines and
Segmentation. Segmentation does not depend on Lines. It has a child
Segmentation.Lines which collects all methods that rely on Lines. An
attempt to write a separate procedure for Segmentation.Lines caused the
problem.

> By the way, it is under some circumstances legal (though very
> bad practice to write)
>
> with Standard.A;
>
> If you really understand things by now, you should be able to
> figure out the conditions.
>
> We can only *with* a library unit, so the above is legal only
> if there is a library unit Standard and a child Standard.A.

It is clear that there is no need to *with* Standard for it is always
*withed*. The question is what the name of a library unit is. Does it
include "Standard." as prefix or not. IF the fully qualified name of A
is Standard.A, then "with Standard.A; use Standard.A;" SHALL be correct.

> Well we learned from above that the Standard that is in the RM
> is NOT a library unit, but rather the parent of all library
> units, so the above must imply that there is another Standard
> that is a library unit.

If it is not a unit, not a thing, why does it have a name? Something
that does not exist need not to be specified.

Regards,
Dmitry Kazakov


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Common ancestor (visibility rules)

[Robert Dewar]

In article <8bt42b$tfe$1@nnrp1.deja.com>,
  dmitry6243@my-deja.com wrote:
> In article <8bskgp$ctu$1@nnrp1.deja.com>,
> Robert Dewar <dewar@gnat.com> wrote:
> with A; use A;           -- OK with Aonix, error in GNAT
>(v3.12)

The above is perfectly fine, and compiles fine with all versions
of GNAT, you are either compiling code different from what
you quoted, or you have a messed up copy of GNAT.

> I.e. Standard is a unit, but not a library unit. Then there
seems to be
> two arts of unit names: library names starting with Standard
that can be
> *used* but not *withed*, then "un-library" names without
Standard
> prefix. They can be *withed* and sometimes *used*. Right?

No one EVER needs to use a diction like

with A; use Standard.A;

so it is a waste of time to discuss it. and your two "arts"
of unit names is pure confusion, please carefully reread my
previous post (I don't know how to make it clearer!)

> It is works in GNAT and illegal in Aonix, but see above.

I *think* it should be legal, but since no one would ever
write this, it is totally pointless, it is not important.


> So GNAT is wrong?

No, of course GNAT handles this right. You should perhaps
publish the ENTIRE code you have that GNAT rejected. You
gave two quite different examples of code so far, and
neither had with A; use A; in it.

> I do not see how. Either Standard.A is the name of A or not.
If yes then
> why "with Standard.A;" is illegal. If not, why "use
Standard.A;" is
> legal.

My previous post really answered this quite clearly.

> It is clear that there is no need to *with* Standard for it is
always
> *withed*. The question is what the name of a library unit is.
Does it
> include "Standard." as prefix or not. IF the fully qualified
name of A
> is Standard.A, then "with Standard.A; use Standard.A;" SHALL
be correct.

That's quite wrong, please reread my previous note.

I will say the rule once more, after that you really need to
read and figure it out :-)

You can only WITH a library unit, library units are the units
that are child units of Standard.

So if you say

  with Standard.A;

you are saying that Standard.A is a library unit, i.e. that
it is a child of Standard, i.e. that its fully qualified nanme
is Standard.Standard.A.

The fully qualified name always includes Standard, but you can
NOT use this fully qualified name in a WITH clause!



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Common ancestor (visibility rules)

[dmitry6243]

In article <8bu64t$60h$1@nnrp1.deja.com>,
Robert Dewar <robert_dewar@my-deja.com> wrote:

> > with A; use A; -- OK with Aonix, error in GNAT
> >(v3.12)
>
> The above is perfectly fine, and compiles fine with all versions
> of GNAT, you are either compiling code different from what
> you quoted, or you have a messed up copy of GNAT.

b-a.adb:1:13: "A" is not a usable package

> No, of course GNAT handles this right. You should perhaps
> publish the ENTIRE code you have that GNAT rejected. You
> gave two quite different examples of code so far, and
> neither had with A; use A; in it.

-------------- a.ads
package A is
   procedure Foo;
end A;
-------------- b.ads
package B is
   procedure A;
end B;
-------------- b.adb
package body B is
   procedure A is separate;
end B;
-------------- b-a.adb
with A; use A;
separate (B)
procedure A is
begin
   Foo;
end A;
===========================================
>gcc -c b-a.adb
b-a.adb:1:13: "A" is not a usable package
b-a.adb:5:04: "Foo" is not visible
b-a.adb:5:04: non-visible declaration at a.ads:2

> I will say the rule once more, after that you really need to
> read and figure it out :-)
>
> You can only WITH a library unit, library units are the units
> that are child units of Standard.
>
> So if you say
>
> with Standard.A;
>
> you are saying that Standard.A is a library unit, i.e. that
> it is a child of Standard, i.e. that its fully qualified nanme
> is Standard.Standard.A.
>
> The fully qualified name always includes Standard, but you can
> NOT use this fully qualified name in a WITH clause!

In other words:

1. Fully qualified names cannot be used in WITH clause;
2. Fully qualified names can be used in USE clause;

Here "fully qualified name" stays for a name beginning from Standard (I
mean the predefined one). As a consequence, WITH and USE clauses use
different names. This is what I meant talking about "two diffrent kinds
of names".

Had I figured it out? (:-))

P.S. You know it for sure. Does ALRM cease to exist? It worked much
better to me. I cannot find a new version, mine is dated 1992! (:-().

Regards,
Dmitry Kazakov


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Common ancestor (visibility rules)

[Tucker Taft]

dmitry6243@my-deja.com wrote:
> 
> In article <8bu64t$60h$1@nnrp1.deja.com>,
> Robert Dewar <robert_dewar@my-deja.com> wrote:
> 
> > > with A; use A; -- OK with Aonix, error in GNAT
> > >(v3.12)
> >
> > The above is perfectly fine, and compiles fine with all versions
> > of GNAT, you are either compiling code different from what
> > you quoted, or you have a messed up copy of GNAT.
> 
> b-a.adb:1:13: "A" is not a usable package
> In other words:
> 
> 1. Fully qualified names cannot be used in WITH clause;
> 2. Fully qualified names can be used in USE clause;

GNAT has led you astray.  There appears to be a bug in GNAT.
The Aonix compiler is correct in accepting:

   with A; use A;

and in rejecting

   with A; use Standard.A;


It is true, but potentially confusing, that the visibility
rules in context clauses (the with and use clauses that come
in front of a compilation unit) and the visibility rules
inside of a compilation unit are different.

The visibility rules in context clauses are given in RM95 10.1.6
"Environment-Level Visibility Rules."  The visibility rules are
independent of the compilation unit that follows (though the
*legality* rule 10.1.2(8) does depend on the compilation unit).
The reason for these special visibility rules is that they
are for a clause that precedes the compilation unit, and may affect
some of the names used within the compilation unit spec,
so there is a potential chicken-and-egg problem if the visibility
in context clauses depended on the compilation unit that followed.

In any case, the basic rule is that *all* names used in a context
clause must be "full" expanded names, but *omitting* the
"Standard." part.  No hiding can happen, since only full names
are allowed, all of which start at the same point in the name space
(immediately within package Standard).  In fact, "with Standard.A;" would
be interpreted as requesting that the library unit whose
name-from-the-very-root is Standard.Standard.A be made visible.

Once you get inside a compilation unit, the rules are different,
and full expanded names are not required, though they may be
used to overcome name hiding.  And names-from-the-very-root (i.e.
those that start with Standard) may also be used.  But as mentioned
above, such names may *not* be used in context clauses.

> Here "fully qualified name" stays for a name beginning from Standard (I
> mean the predefined one). As a consequence, WITH and USE clauses use
> different names. This is what I meant talking about "two diffrent kinds
> of names".
> 
> Had I figured it out? (:-))

As mentioned above, GNAT has misled you.  The WITH and USE clauses
that appear in a context clause both obey the "environment-level"
visibility rules given in 10.1.6, with the added proviso that a USE
clause can only mention a unit that has already been mentioned in
a prior WITH clause.

>
> P.S. You know it for sure. Does ALRM cease to exist? It worked much
> better to me. I cannot find a new version, mine is dated 1992! (:-().

There is a publically available ALRM on various web sites, including:

   http://www.adaic.org/standards/ada95.html
> 
> Regards,
> Dmitry Kazakov
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Common ancestor (visibility rules)

[dmitry6243]

In article <38E3B8B8.55305DCB@averstar.com>,
Tucker Taft <stt@averstar.com> wrote:

> In any case, the basic rule is that *all* names used in a context
> clause must be "full" expanded names, but *omitting* the
> "Standard." part. No hiding can happen, since only full names
> are allowed, all of which start at the same point in the name space
> (immediately within package Standard). In fact, "with Standard.A;"
would
> be interpreted as requesting that the library unit whose
> name-from-the-very-root is Standard.Standard.A be made visible.
>
> Once you get inside a compilation unit, the rules are different,
> and full expanded names are not required, though they may be
> used to overcome name hiding. And names-from-the-very-root (i.e.
> those that start with Standard) may also be used. But as mentioned
> above, such names may *not* be used in context clauses.

Thank you. It is crystal clear now. A bit confusing that in different
places one should use different names, but I understand the drawbacks of
the alternative of obligatory specifying the "Standard." prefix in WITH
and USE.

> There is a publically available ALRM on various web sites, including:
>
> http://www.adaic.org/standards/ada95.html

Just downloaded it (:-)) Thanks a lot.

Regards,
Dmitry Kazakov


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Common ancestor (visibility rules)

[Robert Dewar]

In article <38E3B8B8.55305DCB@averstar.com>,
  Tucker Taft <stt@averstar.com> wrote:
> GNAT has led you astray.  There appears to be a bug in GNAT.
> The Aonix compiler is correct in accepting:
>
>    with A; use A;

Well to be a little more accurate, some version of GNAT that
the user is using may malfunction, but the current version of
GNAT most certainly accepts this as one would expect (and as
I noted in previous versions). Yes indeed, this is the proper
way of doing things!




Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Common ancestor (visibility rules)

[Robert Dewar]

In article <38E3B8B8.55305DCB@averstar.com>,
  Tucker Taft <stt@averstar.com> wrote:

> It is true, but potentially confusing, that the visibility
> rules in context clauses (the with and use clauses that come
> in front of a compilation unit) and the visibility rules
> inside of a compilation unit are different.

Of course this is not normally an issue, except in this
contorted subunit case, which shows exactly why the rule
is the way it is. Actually I don't think the language is
really confusing here, just the formal rules :-)

  "with A; use A;"

is the natural way to write things in this case, and most
programmers will write this without thinking about it. And
indeed of course most programmers will avoid this kind of
duplication of names anyway, though the example does
realistically show how it could arise by "accident".

Probably the history here is that dmitry first just wrote
with A; use A; and then ran into trouble with the old version
of GNAT. Then left out the troublesome "use A", then ran into
trouble with not knowing to use Standard for the reference.

My taste here would be to *avoid* the use of the use clause
in any case. You really don't want to use USE clauses when
you have this kind of confusion of names.

The writer of the main unit here may not know about the clash
of names for A, but the writer of the subunit sure does, and
if there ever was a case where USE clauses should be avoided
this is it, since you have two units around called A, and
it will not be at all helpful to simply use A without making
it clear which A you are talking about. Indeed I would be
tempted in this situation not only to avoid the use clause,
but also to qualify the subprogram A.

In other words, given this name clash, I would always write

   B.A for the subprogram

   Standard.A for the library package

That will help the reader of this subunit sort through the
unfortunate name clash. Note that if you follow this advice
the one place you cannot use B.A is in the spec of the
subprogram itself, but that's OK since separate (B) is
right there, and no confusion arises.

P.S. It is indeed a real bug in GNAT that it accepts Standard.A.
Certainly a rather obscure bug that might have layed dormant for
a very long time :-)



Sent via Deja.com http://www.deja.com/
Before you buy.