Re: Ada 95 visibility question

Re: Ada 95 visibility question

[Chris Sparks (Mr. Ada)]

Robert A Duff <bobduff@WORLD.STD.COM> wrote:

> >package body c.f is
> >  procedure p(x:in out file_dialog) is
> >    y:integer;
> >  begin
> >    y:=root(x).peek_a_boo;
> >    y:=x.peek_a_boo;  1/3 of compilers tested complained
>
> This is illegal.  Dialog has a peek_a_boo component implicitly declared
> in the private part of c.d.  There is no place within the immediate
> scope of file_dialog where this private part is visible, so file_dialog
> doesn't declare peek_a_boo.  (It's still there at run time, but you can
> only get at it by doing a type conversion, as shown above.)

Wouldn't peek_a_boo be visible since the types are part of the "c" (no
pun
intended) hierarchy?

Chris Sparks

Re: Ada 95 visibility question

[Bruce Link]

Chris Sparks (Mr. Ada) (mrada@CATALINA-INTER.NET) wrote:
: Robert A Duff <bobduff@WORLD.STD.COM> wrote:
: 
: > >package body c.f is
: > >  procedure p(x:in out file_dialog) is
: > >    y:integer;
: > >  begin
: > >    y:=root(x).peek_a_boo;
: > >    y:=x.peek_a_boo;  1/3 of compilers tested complained
: >
: > This is illegal.  Dialog has a peek_a_boo component implicitly declared
: > in the private part of c.d.  There is no place within the immediate
: > scope of file_dialog where this private part is visible, so file_dialog
: > doesn't declare peek_a_boo.  (It's still there at run time, but you can
: > only get at it by doing a type conversion, as shown above.)
: 
: Wouldn't peek_a_boo be visible since the types are part of the "c" (no
: pun
: intended) hierarchy?
: 
: Chris Sparks
Robert Duff cites 7.3.1 (no paragraph), but this does not seem to apply in
the way he intends it.  7.1(7) says an entity declared in the private part of
a package is visible only within the declarative region of the package
itself (including any child units).  I would say that the construct is legal
(after much chasing around in section 8.1, 7.2, and 10.1.1).  Without the 
legalities, I understood, as Chris, that the contents of the private part 
of a package were visible in the specs of private children, and the private
sections and bodies of all children.

-- 
----------------------------------------------------------------------------
Bruce Link                         |Team OS/2
bdl@mda.ca                         |Team Ada

Re: Ada 95 visibility question

[Tucker Taft]

Bruce Link (bdl@mda.ca) wrote:

: ...
: Robert Duff cites 7.3.1 (no paragraph), but this does not seem to apply in
: the way he intends it.  

Bob is right, but 7.3.1 is not exactly crystal clear on the topic.
Slightly better is AI95-00157.  The key thing to realize is
that knowing anything about the grandparent of a derived type is 
irrelevant.

All that matters is what characteristics of the immediate parent 
type are *visible* in the immediate scope of the derived type.

In this case, because the parent type is defined in a sibling package,
rather than an ancestor package, one only sees the public characteristics
of the parent type, and even though you "know" more about the grandparent
type, that is irrelevant.  

The only way to take advantage of what is known about a grandparent 
type is to convert to that grandparent type.

: Bruce Link                         |Team OS/2
: bdl@mda.ca                         |Team Ada

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA

Re: Ada 95 visibility question

[Robert A Duff]

In article <342A7989.219C@catalina-inter.net>,
Chris Sparks (Mr. Ada) <mrada@CATALINA-INTER.NET> wrote:
>Wouldn't peek_a_boo be visible since the types are part of the "c" (no
>pun intended) hierarchy?

No.  It's not unreasonable to think that ought to be the case, but the
actual rules in the RM say otherwise.  As I said, it's a subtle issue.

You inherit from your parent, not your grandparent.  You inherit stuff
from your grandparent only because your parent inherited those things.
And your visibility on those things depends on your visibility of your
parent.  In this case, you know who your grandparent is, and you know it
has the Peek_A_Boo component, but you don't know *you* have that
component.  It's just a minor oddity caused by Ada's model of always
having an imaginary (implicit) declaration for these things, which
occurs (or is imagined to occur) in some well-defined place in the
program.

- Bob

Ada 95 visibility question

[Tom Moran]

Of three compilers I tried this on, 2 took it happily and one said it
couldn't find such a thing as "peek_a_boo" at the place indicated. 
What's correct?
package c is
  type root is tagged private;
private
  type root is tagged record
    peek_a_boo:integer;
  end record;
end c;

package c.d is
  type dialog is new c.root with private;
private
  type dialog is new c.root with record
    dd:integer;
  end record;
end c.d;

with c.d;
package c.f is
  type file_dialog is new c.d.dialog with private;
  procedure p(x:in out file_dialog);
private
  type file_dialog is new c.d.dialog with record
    ff:integer;
  end record;
end c.f;

package body c.f is
  procedure p(x:in out file_dialog) is
    y:integer;
  begin
    y:=root(x).peek_a_boo;
    y:=x.peek_a_boo;  1/3 of compilers tested complained
  end p;
end c.f;

with c.f;
procedure bug1 is
  f:c.f.file_dialog;
begin
  c.f.p(f);
end bug1;

Re: Ada 95 visibility question

[Robert A Duff]

In article <3424860A.2777@bix.com>, Tom Moran  <tmoran@bix.com> wrote:
>Of three compilers I tried this on, 2 took it happily and one said it
>couldn't find such a thing as "peek_a_boo" at the place indicated. 
>What's correct?

This is a pretty subtle question.  The rules are in 7.3.1.

The 1 compiler is correct; the other 2 are wrong.  :-(

>package c is
>  type root is tagged private;
>private
>  type root is tagged record
>    peek_a_boo:integer;
>  end record;
>end c;
>
>package c.d is
>  type dialog is new c.root with private;
>private
>  type dialog is new c.root with record
>    dd:integer;
>  end record;
>end c.d;
>
>with c.d;
>package c.f is
>  type file_dialog is new c.d.dialog with private;
>  procedure p(x:in out file_dialog);
>private
>  type file_dialog is new c.d.dialog with record
>    ff:integer;
>  end record;
>end c.f;
>
>package body c.f is
>  procedure p(x:in out file_dialog) is
>    y:integer;
>  begin
>    y:=root(x).peek_a_boo;
>    y:=x.peek_a_boo;  1/3 of compilers tested complained

This is illegal.  Dialog has a peek_a_boo component implicitly declared
in the private part of c.d.  There is no place within the immediate
scope of file_dialog where this private part is visible, so file_dialog
doesn't declare peek_a_boo.  (It's still there at run time, but you can
only get at it by doing a type conversion, as shown above.)

There's also an AI on this section, but it doesn't affect this
particular case.

>  end p;
>end c.f;
>
>with c.f;
>procedure bug1 is
>  f:c.f.file_dialog;
>begin
>  c.f.p(f);
>end bug1;

- Bob