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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,93dce172c8d3e2fb
X-Google-Attributes: gid103376,public
From: bobduff@world.std.com (Robert A Duff)
Subject: Re: Which compiler is correct?
Date: 1997/06/21
Message-ID: <EC3t3q.BzJ@world.std.com>#1/1
X-Deja-AN: 251520002
References: <33A77C54.5484@bix.com> <EBz083.9EB@world.std.com>
 <ud205z1ifw.fsf@tanana.llnl.gov> <JSA.97Jun20185414@alexandria.organon.com>
Organization: The World Public Access UNIX, Brookline, MA
Newsgroups: comp.lang.ada
Date: 1997-06-21T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <JSA.97Jun20185414@alexandria.organon.com>,
Jon S Anthony <jsa@alexandria.organon.com> wrote:
>In article <ud205z1ifw.fsf@tanana.llnl.gov> woodruff@tanana.llnl.gov (John Woodruff) writes:
...
>> package Parent.Child is
>>    type Good_Obj is new Parent.Obj with private ;
>>    type Bad_Obj  is new Parent.Obj with null record ;
>
>NOTE: at this point
>
>a) Parent's i component is _not_ visible and so not available to this
>view of the children.

Right.

>b) Bad_Obj is _fully_ declared at this point and so will never get the
>implicit declaration of Parent's i component.

No, that's not quite right.

>>    procedure Do_Nothing ;  -- just to require body

By the way, "pragma Elaborate_Body;" is a good way to require a body,
when it's not otherwise required.

>> private

At *this* point, an "additional characteristic" (see 7.3.1(3-4)) of
Parent.Obj (namely, the existence of I) becomes visible, and since this
is within the immediate scope of Bad_Obj, it gets an I, too.  By magic.

Note: There's an AI that says this happens only *immediately* within the
immediate scope of Bad_Obj, to match Ada 83.  (The wording of RM95
accidentally lets it happen *anywhere* within the immediate scope of
Bad_Obj, which is wrong.)  That's irrelevant to this example.

>>    type Good_Obj is new Parent.Obj with null record ;
>
>At this point, Parent.I is visible and the full declaration of
>Good_Obj implicitly declares this component.
>
>
>> end ;
>> 
>> One of the compilers (compiler "r") is able to compile the body without
>> error; the other compiler reports an error in the body when I try to
>> reference the component of the parent type.
>> 
>> package body Parent.Child is
>>    good : Good_Obj ;
>>    Bad  : Bad_Obj ;
>>    procedure Do_Nothing is
>>    begin
>>       null;
>>    end ;
>> begin
>>    Good.I := 2 ;
>>    Bad.I := 2 ;  -- compiler "g" reports error
>> end ;
>
>So, Bad.I is not directly available and compiler "g", I believe, is
>correct.

No.

>> selector".  I am unable to think of a reason why the body of the child
>> package can reference the parent's private declaration of Obj for one,
>> but not for the other derived types.
>
>I think this all falls out of the rules in 7.3.1, and in particular
>pay close attention to what is said in (3).

Closer attention than that.  ;-)

- Bob