* Which compiler is correct?
@ 1997-06-17 0:00 Tom Moran
1997-06-18 0:00 ` Pascal Obry
1997-06-18 0:00 ` Robert A Duff
0 siblings, 2 replies; 26+ messages in thread
From: Tom Moran @ 1997-06-17 0:00 UTC (permalink / raw)
Compilers G and J accept this code. Compiler O gives the error message
indicted in the comment, on said line. Which is correct Ada?
package a is
type x is tagged private;
private
type x is tagged record
i:integer;
end record;
end a;
package a.b is
type y is new x with private;
private
type y is new x with record
j:integer;
end record;
end a.b;
with a.b;
package a.c is
type z is new a.b.y with private;
procedure p;
private
type z is new a.b.y with record
k:integer;
end record;
end a.c;
package body a.c is
procedure p is
one:x;
two:z;
begin
one.i:=1;
two.k:=2;
two.i:=3; -- test_vis.ada: Error: line 31 col 13 LRM:4.1.3(5),
No possible interpretation for selected component i, Ignoring future
references
end p;
end a.c;
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Which compiler is correct?
1997-06-17 0:00 Which compiler is correct? Tom Moran
@ 1997-06-18 0:00 ` Pascal Obry
1997-06-18 0:00 ` Tom Moran
1997-06-18 0:00 ` Robert A Duff
1 sibling, 1 reply; 26+ messages in thread
From: Pascal Obry @ 1997-06-18 0:00 UTC (permalink / raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 905 bytes --]
It seem to me that compiler G (GNAT) and J (Janus ???) are corrects
and that compiler O (ObjectAda) is wrong.
Pascal.
--
--|------------------------------------------------------------
--| Pascal Obry Team-Ada Member |
--| |
--| EDF-DER-IPN-SID- Ing�nierie des Syst�mes d'Informations |
--| |
--| Bureau G1-010 e-mail: pascal.obry@der.edfgdf.fr |
--| 1 Av G�n�ral de Gaulle voice : +33-1-47.65.50.91 |
--| 92141 Clamart CEDEX fax : +33-1-47.65.50.07 |
--| FRANCE |
--|------------------------------------------------------------
--|
--| http://ourworld.compuserve.com/homepages/pascal_obry
--|
--| "The best way to travel is by means of imagination"
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Which compiler is correct?
1997-06-17 0:00 Which compiler is correct? Tom Moran
1997-06-18 0:00 ` Pascal Obry
@ 1997-06-18 0:00 ` Robert A Duff
1997-06-18 0:00 ` John Woodruff
1997-06-19 0:00 ` Simon Wright
1 sibling, 2 replies; 26+ messages in thread
From: Robert A Duff @ 1997-06-18 0:00 UTC (permalink / raw)
In article <33A77C54.5484@bix.com>, Tom Moran <tmoran@bix.com> wrote:
>Compilers G and J accept this code. Compiler O gives the error message
>indicted in the comment, on said line. Which is correct Ada?
Compiler O is correct. The inherited i component of type y is
implicitly declared within the private part of a.b. Since a.c cannot
see this implicit declaration, the i component of z is never implicitly
declared (although it still exists at run time, and you can get at it by
doing "x(two).i").
The rules for this stuff are somewhat arcane. See 3.4 and 7.3.1.
>package a is
> type x is tagged private;
>private
> type x is tagged record
> i:integer;
> end record;
>end a;
>package a.b is
> type y is new x with private;
>private
> type y is new x with record
> j:integer;
> end record;
>end a.b;
>with a.b;
>package a.c is
> type z is new a.b.y with private;
> procedure p;
>private
> type z is new a.b.y with record
> k:integer;
> end record;
>end a.c;
>package body a.c is
> procedure p is
> one:x;
> two:z;
> begin
> one.i:=1;
> two.k:=2;
> two.i:=3; -- test_vis.ada: Error: line 31 col 13 LRM:4.1.3(5),
>No possible interpretation for selected component i, Ignoring future
>references
>
> end p;
>end a.c;
- Bob
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Which compiler is correct?
1997-06-18 0:00 ` Robert A Duff
@ 1997-06-18 0:00 ` John Woodruff
1997-06-19 0:00 ` Robert A Duff
1997-06-20 0:00 ` Jon S Anthony
1997-06-19 0:00 ` Simon Wright
1 sibling, 2 replies; 26+ messages in thread
From: John Woodruff @ 1997-06-18 0:00 UTC (permalink / raw)
>>>>> "bobduff" == Robert A Duff <bobduff@world.std.com> writes:
In article <EBz083.9EB@world.std.com> bobduff@world.std.com (Robert A Duff) writes:
> In article <33A77C54.5484@bix.com>, Tom Moran <tmoran@bix.com>
> wrote:
>> Compilers G and J accept this code. Compiler O gives the error
>> message indicted in the comment, on said line. Which is correct
>> Ada?
(deletia)
> The rules for this stuff are somewhat arcane. See 3.4 and 7.3.1.
(tacit agreement, followed by a new case:)
Here is another inquiry of the type "which compiler is correct." It is
so similar to the issue Bob answered for Tom that I retain the thread
(and the answer Bob gave is so clear that I imagine that this one will
be equally easy to understand once I know the answer.)
Let me define a package with a tagged private type:
package Parent is
type Obj is tagged private ;
private
type Obj is tagged record
I : Integer ;
end record ;
end Parent ;
The package has just one child that extends the type. Depending on the
specifics of how I derive the new type, I get correct code or code that
evokes an error message that I don't understand:
package Parent.Child is
type Good_Obj is new Parent.Obj with private ;
type Bad_Obj is new Parent.Obj with null record ;
procedure Do_Nothing ; -- just to require body
private
type Good_Obj is new Parent.Obj with null record ;
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 ;
According to one compiler the component of type Bad_Obj is an "undefined
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.
--
John Woodruff N I F \ ^ /
Lawrence Livermore National Lab =====---- < 0 >
510 422 4661 / v \
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Which compiler is correct?
1997-06-18 0:00 ` John Woodruff
@ 1997-06-19 0:00 ` Robert A Duff
1997-06-20 0:00 ` Jon S Anthony
1 sibling, 0 replies; 26+ messages in thread
From: Robert A Duff @ 1997-06-19 0:00 UTC (permalink / raw)
In article <ud205z1ifw.fsf@tanana.llnl.gov>,
John Woodruff <woodruff1@llnl.gov> wrote:
> > The rules for this stuff are somewhat arcane. See 3.4 and 7.3.1.
> (tacit agreement, followed by a new case:)
;-)
>Here is another inquiry of the type "which compiler is correct." ...
First of all, you and the earlier poster need a strong lecture, or
perhaps should be sent back to remedial programming school. Why?
Because you use one-letter identifier names for compilers (r and g,
here). Or are you trying to mimic those stupid laundry soap ads that
talk about "the leading brand" without naming it?
;-) ;-)
> Bad.I := 2 ; -- compiler "g" reports error
Looks legal to me. See 7.3.1(4). If you don't understand it, execute
the following in your head:
<<Label>>
Read 7.3.1;
goto Label;
And when this completes, all will be clear. And then I'll *goto*
remedial programming school, for uttering the cuss word "goto".
In case you hadn't guessed, I don't much like 7.3.1.
See also 3.4(14.b).
>According to one compiler the component of type Bad_Obj is an "undefined
>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.
In the business, we call this a "bug". ;-)
- Bob
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Which compiler is correct?
1997-06-18 0:00 ` John Woodruff
1997-06-19 0:00 ` Robert A Duff
@ 1997-06-20 0:00 ` Jon S Anthony
1997-06-21 0:00 ` Robert A Duff
1 sibling, 1 reply; 26+ messages in thread
From: Jon S Anthony @ 1997-06-20 0:00 UTC (permalink / raw)
In article <ud205z1ifw.fsf@tanana.llnl.gov> woodruff@tanana.llnl.gov (John Woodruff) writes:
> Here is another inquiry of the type "which compiler is correct." It is
> so similar to the issue Bob answered for Tom that I retain the thread
> (and the answer Bob gave is so clear that I imagine that this one will
> be equally easy to understand once I know the answer.)
>
> Let me define a package with a tagged private type:
> package Parent is
> type Obj is tagged private ;
> private
> type Obj is tagged record
> I : Integer ;
> end record ;
> end Parent ;
>
> The package has just one child that extends the type. Depending on the
> specifics of how I derive the new type, I get correct code or code that
> evokes an error message that I don't understand:
>
> 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.
b) Bad_Obj is _fully_ declared at this point and so will never get the
implicit declaration of Parent's i component.
> procedure Do_Nothing ; -- just to require body
> private
> 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.
> 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).
/Jon
--
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha! The way my life's been going lately,
Who'd notice?" -- Londo Mollari
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Which compiler is correct?
1997-06-20 0:00 ` Jon S Anthony
@ 1997-06-21 0:00 ` Robert A Duff
1997-06-26 0:00 ` Jon S Anthony
0 siblings, 1 reply; 26+ messages in thread
From: Robert A Duff @ 1997-06-21 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Which compiler is correct?
1997-06-21 0:00 ` Robert A Duff
@ 1997-06-26 0:00 ` Jon S Anthony
0 siblings, 0 replies; 26+ messages in thread
From: Jon S Anthony @ 1997-06-26 0:00 UTC (permalink / raw)
In article <EC3t3q.BzJ@world.std.com> bobduff@world.std.com (Robert A Duff) writes:
> >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.
By which you mean that it _will_ get Parent's i component eventually
even though it is fully declared here, right? So, being a private
declaration is irrelevant. I think that is what I let lead me astray.
> >> 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.
^^^^^^^^
;-).
> >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. ;-)
:-). The odd thing is, that going back and reading it just now (and
(4)...) after reading your comments here, it seems pretty darn clear
and straight-forward.
/Jon
--
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha! The way my life's been going lately,
Who'd notice?" -- Londo Mollari
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Which compiler is correct?
1997-06-18 0:00 ` Robert A Duff
1997-06-18 0:00 ` John Woodruff
@ 1997-06-19 0:00 ` Simon Wright
1997-06-20 0:00 ` Jon S Anthony
1997-06-21 0:00 ` Robert A Duff
1 sibling, 2 replies; 26+ messages in thread
From: Simon Wright @ 1997-06-19 0:00 UTC (permalink / raw)
bobduff@world.std.com (Robert A Duff) writes:
> In article <33A77C54.5484@bix.com>, Tom Moran <tmoran@bix.com> wrote:
> >Compilers G and J accept this code. Compiler O gives the error message
> >indicted in the comment, on said line. Which is correct Ada?
>
> Compiler O is correct. The inherited i component of type y is
> implicitly declared within the private part of a.b. Since a.c cannot
> see this implicit declaration, the i component of z is never implicitly
> declared (although it still exists at run time, and you can get at it by
> doing "x(two).i").
a.c's body can see the full view of type a.x
a.c's body can only see the partial view of type a.b.y
the partial view of type a.b.y says it's a new a.x
so how come the a.x bits of a.b.y aren't visible to a.c's body?
(I'm sure it's true if you say so; I just think most people, after
they've seen this sort of problem and fumbled their way to a
resolution a few times, will have a private spellbook from which they
will select incantations until they find one that works. So what's
new, you say)
--
Simon Wright Work Email: simon.j.wright@gecm.com
GEC-Marconi Radar & Defence Systems Voice: +44(0)1705-701778
Command & Information Systems Divsion FAX: +44(0)1705-701800
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Which compiler is correct?
1997-06-19 0:00 ` Simon Wright
@ 1997-06-20 0:00 ` Jon S Anthony
1997-06-21 0:00 ` Robert A Duff
1997-06-21 0:00 ` Robert A Duff
1 sibling, 1 reply; 26+ messages in thread
From: Jon S Anthony @ 1997-06-20 0:00 UTC (permalink / raw)
In article <x7vyb86jpr2.fsf@pogner.demon.co.uk> Simon Wright <simon@pogner.demon.co.uk> writes:
> bobduff@world.std.com (Robert A Duff) writes:
>
> > Compiler O is correct. The inherited i component of type y is
> > implicitly declared within the private part of a.b. Since a.c cannot
> > see this implicit declaration, the i component of z is never implicitly
> > declared (although it still exists at run time, and you can get at it by
> > doing "x(two).i").
>
> a.c's body can see the full view of type a.x
> a.c's body can only see the partial view of type a.b.y
> the partial view of type a.b.y says it's a new a.x
> so how come the a.x bits of a.b.y aren't visible to a.c's body?
I believe this is due to the "fact" (from 7.3.1(3)) that the only
characteristics used from the parent of x for y _at its declaration_
are those visible _at that point_. The i component of the parent x is
not visible until the full declaration in the private portion and it
is only at that point that the implicit declaration for y's i
component can take place. So, the declaration of y visible to a.c
does not have the implicit declaration of x's i component.
Why this is, I do not know.
/Jon
--
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha! The way my life's been going lately,
Who'd notice?" -- Londo Mollari
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Which compiler is correct?
1997-06-20 0:00 ` Jon S Anthony
@ 1997-06-21 0:00 ` Robert A Duff
0 siblings, 0 replies; 26+ messages in thread
From: Robert A Duff @ 1997-06-21 0:00 UTC (permalink / raw)
In article <JSA.97Jun20183551@alexandria.organon.com>,
Jon S Anthony <jsa@alexandria.organon.com> wrote:
>Why this is, I do not know.
Why this is in Ada 95 is an easy question to answer: it's analogous to
the Ada 83 rule, but extended to handle child packages. Why it was in
Ada 83, I'm not so sure. I guess the idea is that everything has to be
declared at some particular place in the program (and in these cases,
we're talking about *implicitly* declared), and given that, you have the
normal visibility rules for declarations.
- Bob
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Which compiler is correct?
1997-06-19 0:00 ` Simon Wright
1997-06-20 0:00 ` Jon S Anthony
@ 1997-06-21 0:00 ` Robert A Duff
1997-06-21 0:00 ` Simon Wright
1997-06-23 0:00 ` Mats.Weber
1 sibling, 2 replies; 26+ messages in thread
From: Robert A Duff @ 1997-06-21 0:00 UTC (permalink / raw)
In article <x7vyb86jpr2.fsf@pogner.demon.co.uk>,
Simon Wright <simon@pogner.demon.co.uk> wrote:
>a.c's body can see the full view of type a.x
>a.c's body can only see the partial view of type a.b.y
>the partial view of type a.b.y says it's a new a.x
>so how come the a.x bits of a.b.y aren't visible to a.c's body?
Because the RM says so. ;-)
>(I'm sure it's true if you say so; I just think most people, after
>they've seen this sort of problem and fumbled their way to a
>resolution a few times, will have a private spellbook from which they
>will select incantations until they find one that works. So what's
>new, you say)
The idea here, is that when you say "type New_Type is new Old_Type ...",
the properties of New_Type are frozen at that point. EXCEPT when this
declaration is inside where Old_Type is declared -- then, at the
earliest place within New_Type's immediate scope where it can see some
additional information about Old_Type, then that information becomes
visible for New_Type. Usually, this doesn't happen. When it does
happen, it's either at the beginning of a private part of a child
package, or at the beginning of the body of a physically-nested package.
Yes, this leads to surprising consequences, like where you're at a place
that *knows* New_Type is derived from Old_Type, and *knows* that
Old_Type has a component Foo, but nonetheless, Foo is not a visible
component of New_Type.
This can be confusing, but at least the confusion happens at compile
time, not at run time. :-)
- Bob
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Which compiler is correct?
1997-06-21 0:00 ` Robert A Duff
@ 1997-06-21 0:00 ` Simon Wright
1997-06-23 0:00 ` Mats.Weber
1 sibling, 0 replies; 26+ messages in thread
From: Simon Wright @ 1997-06-21 0:00 UTC (permalink / raw)
bobduff@world.std.com (Robert A Duff) writes:
[my ramblings deleted]
> This can be confusing, but at least the confusion happens at compile
> time, not at run time. :-)
Yes, of course, I hadn't considered the alternative!
--
Simon Wright Work Email: simon.j.wright@gecm.com
GEC-Marconi Radar & Defence Systems Voice: +44(0)1705-701778
Command & Information Systems Divsion FAX: +44(0)1705-701800
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Which compiler is correct?
1997-06-21 0:00 ` Robert A Duff
1997-06-21 0:00 ` Simon Wright
@ 1997-06-23 0:00 ` Mats.Weber
1997-06-24 0:00 ` Jon S Anthony
1 sibling, 1 reply; 26+ messages in thread
From: Mats.Weber @ 1997-06-23 0:00 UTC (permalink / raw)
In article <EC3tGJ.F0A@world.std.com>,
bobduff@world.std.com (Robert A Duff) wrote:
> The idea here, is that when you say "type New_Type is new Old_Type ...",
> the properties of New_Type are frozen at that point. EXCEPT when this
> declaration is inside where Old_Type is declared -- then, at the
> earliest place within New_Type's immediate scope where it can see some
> additional information about Old_Type, then that information becomes
> visible for New_Type. Usually, this doesn't happen. When it does
> happen, it's either at the beginning of a private part of a child
> package, or at the beginning of the body of a physically-nested package.
Sorry, but I still don't get it. What is wrong with the following
interpretation of the rules ?
package a is
type x is tagged private;
private
type x is tagged record
i:integer;
end record;
end a;
package a.b is
type y is new x with private;
This establishes, among other things, that y inherits x's components.
private
type y is new x with record
j:integer;
end record;
end a.b;
with a.b;
package a.c is
type z is new a.b.y with private;
As y is visibly derived from x, we know that z is an ancestor of x.
procedure p;
private
From here on, we have visibility on a's private part, and hence on the
full declaration of x. The "additional characteristic" that y has an i
component becomes visible (because y inherits x's components, and that
fact was already established in y's private declaration).
type z is new a.b.y with record
k:integer;
end record;
end a.c;
package body a.c is
procedure p is
one:x;
two:z;
begin
one.i:=1;
two.k:=2;
two.i:=3; -- test_vis.ada: Error: line 31 col 13 LRM:4.1.3(5),
No possible interpretation for selected component i, Ignoring future
references
end p;
end a.c;
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Which compiler is correct?
1997-06-23 0:00 ` Mats.Weber
@ 1997-06-24 0:00 ` Jon S Anthony
0 siblings, 0 replies; 26+ messages in thread
From: Jon S Anthony @ 1997-06-24 0:00 UTC (permalink / raw)
In article <867075736.16958@dejanews.com> Mats.Weber@elca-matrix.ch writes:
<<emailed as well...>>
> Sorry, but I still don't get it. What is wrong with the following
> interpretation of the rules ?
>
> package a is
> type x is tagged private;
> private
> type x is tagged record
> i:integer;
> end record;
> end a;
> package a.b is
> type y is new x with private;
>
> This establishes, among other things, that y inherits x's components.
Aha! This is where you are confused. This does _not_ establish that
y inherits x's components because they are not yet visible. See 7.3.1
and pay particular attention to (3).
> private
> type y is new x with record
> j:integer;
> end record;
It is at this point that x's components are visible and it is only at
that point (when they become visible) that they are implicitly
declared.
> end a.b;
> with a.b;
> package a.c is
> type z is new a.b.y with private;
>
> As y is visibly derived from x, we know that z is an ancestor of x.
True, but since a.c does not see the private portion of a.b it does
not see the implicitly declared components of y inherited from x,
because the declaration that it does see does not have them.
> full declaration of x. The "additional characteristic" that y has an i
> component becomes visible
No, since a.c does not have visibility to a.b's private portion, these
components are not directly visible (they are there, you just can't
see them unless you convert).
> (because y inherits x's components, and that
> fact was already established in y's private declaration).
And that is why they aren't directly visible to a.c, as a.c can't see
y's full declaration in a.b's private portion.
/Jon
--
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha! The way my life's been going lately,
Who'd notice?" -- Londo Mollari
^ permalink raw reply [flat|nested] 26+ messages in thread
* Which compiler is correct??
@ 1996-09-10 0:00 Robert B. Love
1996-09-10 0:00 ` Robert Dewar
` (4 more replies)
0 siblings, 5 replies; 26+ messages in thread
From: Robert B. Love @ 1996-09-10 0:00 UTC (permalink / raw)
I've got a situation where I put the same piece of code thru two
compilers on the same hardware and one will compile it, the other
gives errors. The code is listed below and is taken from Richard
Riehle's article in JOOP on "Managing Runtime Faults". GNAT compiles
it fine. Aacademic ObjectAda fails to compile it.
I can see maybe 4 choices: 1) GNAT is wrong, 2) ObjectAda is
wrong, 3) the code is wrong, 4) I need to set some compile
switches on one compiler or the other.
On a PC with GNAT 304a touted as being compiled for Windows and
GNAT 301 on a NeXT/M68040 I get no errors.
With Academic ObjectAda v7.0.171 I get 3 occurrences of the same error
along with line and column numbers.
LRM:6.4.15(5) If the mode is IN OUT or OUT, the actual
shall be a name that denotes a variable.
I need a language lawyer to tell me what is actually wrong.
Note I made 2 change to Riehle's article, commented with "my change"
with ada.exceptions; use ada.exceptions;
with text_io,ada.integer_text_io;use text_io;
procedure exception_demo is
error_list: array(1..3) of exception_occurrence;
d1,d2,d3: integer;
function square(data:integer) return integer is
begin
return data*data;
exception
when error_in_square_function:
constraint_error => ada.exceptions.save_occurrence
(error_in_square_function,error_list(1));
return 0;
end square;
function compute(v1,v2:integer) return integer is
begin
return square(v1) + square(v2);
exception
when error_in_compute:
constraint_error=>ada.exceptions.save_occurrence
(error_in_compute,error_list(2));
return 0; -- my change
end compute;
begin
Ada.Integer_Text_Io.Get(Item=>D1);
Ada.Integer_Text_Io.Get(Item=>D2);
D3 := Compute(V1=>D1,V2=>D2); -- my chanage
exception
when Error_In_Demo:
others => Ada.Exceptions.Save_Occurrence
(Error_In_Demo,Error_List(3));
for I in Error_List'Range loop
Text_Io.Put_Line(Exception_Message(Error_List(I)));
Text_Io.Put_Line(Exception_Name(Error_List(I)));
Text_Io.Put_Line(Exception_Information(Error_List(I)));
end loop;
end exception_demo;
----------------------------------------------------------------
Bob Love, rlove@neosoft.com (local) MIME & NeXT Mail OK
rlove@raptor.rmnug.org (permanent) PGP key available
----------------------------------------------------------------
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Which compiler is correct??
1996-09-10 0:00 Which compiler is correct?? Robert B. Love
@ 1996-09-10 0:00 ` Robert Dewar
1996-09-11 0:00 ` Robert B. Love
1996-09-10 0:00 ` Robert Dewar
` (3 subsequent siblings)
4 siblings, 1 reply; 26+ messages in thread
From: Robert Dewar @ 1996-09-10 0:00 UTC (permalink / raw)
Ah, finally I figured this out (I would have had it immediately, if you had
said where the error message was posted):
exception
when Error_In_Demo:
others => Ada.Exceptions.Save_Occurrence
(Error_In_Demo,Error_List(3));
that's obviously incorrect, Error_In_Demo is a constant, yet you are using
it as the Target for save occurrence. I think you are mixing up target
and source in the call to Save_Occurrence (not surprising, I think they
are the wrong way round too :-)
Anyway, GNAT should certainly post an error message here, these exception
occurrence constants are a little peculiar, and we just missed this. Indeed
it might have gone undetected for a long time if you had not made this
error of having the parameters the wrong way round!
I guess the reason that you did not see the error was that you were
determined that you knew which way round the parameters were. This is
a common occurrence -- you get "trapped" in a bug :-)
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Which compiler is correct??
1996-09-10 0:00 ` Robert Dewar
@ 1996-09-11 0:00 ` Robert B. Love
0 siblings, 0 replies; 26+ messages in thread
From: Robert B. Love @ 1996-09-11 0:00 UTC (permalink / raw)
Cc: dewar
In <dewar.842410917@schonberg> Robert Dewar wrote:
> Ah, finally I figured this out (I would have had it immediately, if
you had
> said where the error message was posted):
Yep, I clearly should've indicated where the errors were.
> exception
> when Error_In_Demo:
> others => Ada.Exceptions.Save_Occurrence
> (Error_In_Demo,Error_List(3));
>
>
> that's obviously incorrect, Error_In_Demo is a constant, yet you are
using
> it as the Target for save occurrence. I think you are mixing up
target
> and source in the call to Save_Occurrence (not surprising, I think
they
> are the wrong way round too :-)
I'm using the JOOP article to learn about exception handling so
followed
it blindly. I guess the answer should always be READ THE LRM & SPEC!!!
> Anyway, GNAT should certainly post an error message here, these
exception
> occurrence constants are a little peculiar, and we just missed this.
Indeed
> it might have gone undetected for a long time if you had not made
this
> error of having the parameters the wrong way round!
So, do I need to file a bug report or will this do?
I'm glad the Thomson product is working correctly. I want the Ada
market to grow and robust products will be a boon to all.
Thanx for all assistance & comments.
----------------------------------------------------------------
Bob Love, rlove@neosoft.com (local) MIME & NeXT Mail OK
rlove@raptor.rmnug.org (permanent) PGP key available
----------------------------------------------------------------
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Which compiler is correct??
1996-09-10 0:00 Which compiler is correct?? Robert B. Love
1996-09-10 0:00 ` Robert Dewar
@ 1996-09-10 0:00 ` Robert Dewar
1996-09-11 0:00 ` Robert A Duff
` (2 subsequent siblings)
4 siblings, 0 replies; 26+ messages in thread
From: Robert Dewar @ 1996-09-10 0:00 UTC (permalink / raw)
"I can see maybe 4 choices: 1) GNAT is wrong, 2) ObjectAda is
wrong, 3) the code is wrong, 4) I need to set some compile
switches on one compiler or the other."
No, it really can't be 3) or 4), for an issue of legality like this
it really must be 1) or 2). Unfortunately it is hard to analyze your
example, because you don't point out where the alledged errors are!
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Which compiler is correct??
1996-09-10 0:00 Which compiler is correct?? Robert B. Love
1996-09-10 0:00 ` Robert Dewar
1996-09-10 0:00 ` Robert Dewar
@ 1996-09-11 0:00 ` Robert A Duff
1996-09-12 0:00 ` Ken Cowan
` (2 more replies)
1996-09-11 0:00 ` Jon S Anthony
1996-09-12 0:00 ` Tucker Taft
4 siblings, 3 replies; 26+ messages in thread
From: Robert A Duff @ 1996-09-11 0:00 UTC (permalink / raw)
In article <514uuu$d8i@uuneo.neosoft.com>,
>I can see maybe 4 choices: 1) GNAT is wrong, 2) ObjectAda is
>wrong, 3) the code is wrong, 4) I need to set some compile
>switches on one compiler or the other.
Looks like 1 and 3, to me. Please send a bug report to ACT --
apparently GNAT doesn't understand that choice parameters are constant.
>On a PC with GNAT 304a touted as being compiled for Windows and
>GNAT 301 on a NeXT/M68040 I get no errors.
>
>With Academic ObjectAda v7.0.171 I get 3 occurrences of the same error
>along with line and column numbers.
>
> LRM:6.4.15(5) If the mode is IN OUT or OUT, the actual
> shall be a name that denotes a variable.
It would have been easier if you had told me *which* line and column
numbers! ;-)
> exception
> when error_in_square_function:
> constraint_error => ada.exceptions.save_occurrence
> (error_in_square_function,error_list(1));
You've got the parameters backwards. Look up the spec of
Save_Occurrence. Note that error_in_square_function is constant (by
RM-1.2(9)), so you can't pass it to an in-out param.
> return 0;
Here, "raise;" would be more appropriate, at least in a real program.
- Bob
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Which compiler is correct??
1996-09-11 0:00 ` Robert A Duff
@ 1996-09-12 0:00 ` Ken Cowan
1996-09-12 0:00 ` Ken Cowan
1996-09-13 0:00 ` Jon S Anthony
2 siblings, 0 replies; 26+ messages in thread
From: Ken Cowan @ 1996-09-12 0:00 UTC (permalink / raw)
I missed the original post ...
In article <DxKIDL.GFu@world.std.com>,
bobduff@world.std.com (Robert A Duff) wrote:
>>With Academic ObjectAda v7.0.171 I get 3 occurrences of the same error
>>along with line and column numbers.
>>
>> LRM:6.4.15(5) If the mode is IN OUT or OUT, the actual
>> shall be a name that denotes a variable.
>
>It would have been easier if you had told me *which* line and column
>numbers! ;-)
BTW, if you click on the message in the output window and press F1, the
IDE would have given you the reference manual section in question. If you
double click it would position you to the variable that was in error.
KC
---------------------------------------------------------
Ken Cowan Thomson Software Products
cowan@east.thomsoft.com 200 Wheeler Rd.
phone: (617) 221-7323 Burlington, MA 01803
fax: (617) 220-6882
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Which compiler is correct??
1996-09-11 0:00 ` Robert A Duff
1996-09-12 0:00 ` Ken Cowan
@ 1996-09-12 0:00 ` Ken Cowan
1996-09-13 0:00 ` Jon S Anthony
2 siblings, 0 replies; 26+ messages in thread
From: Ken Cowan @ 1996-09-12 0:00 UTC (permalink / raw)
In article <DxKIDL.GFu@world.std.com>,
bobduff@world.std.com (Robert A Duff) wrote:
>>With Academic ObjectAda v7.0.171 I get 3 occurrences of the same error
>>along with line and column numbers.
>>
>> LRM:6.4.15(5) If the mode is IN OUT or OUT, the actual
>> shall be a name that denotes a variable.
>
>It would have been easier if you had told me *which* line and column
>numbers! ;-)
BTW, if you click on the message in the output window and press F1, the
IDE would have given you the reference manual section in question. If you
double click it would position you to the variable that was in error.
KC
---------------------------------------------------------
Ken Cowan Thomson Software Products
cowan@east.thomsoft.com 200 Wheeler Rd.
phone: (617) 221-7323 Burlington, MA 01803
fax: (617) 220-6882
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Which compiler is correct??
1996-09-11 0:00 ` Robert A Duff
1996-09-12 0:00 ` Ken Cowan
1996-09-12 0:00 ` Ken Cowan
@ 1996-09-13 0:00 ` Jon S Anthony
2 siblings, 0 replies; 26+ messages in thread
From: Jon S Anthony @ 1996-09-13 0:00 UTC (permalink / raw)
In article <DxMIC7.5tM@thomsoft.com> cowan@east.alsys.com (Ken Cowan) writes:
> BTW, if you click on the message in the output window and press F1, the
> IDE would have given you the reference manual section in question. If you
> double click it would position you to the variable that was in error.
This is very nice. I really do need to get my hands on this thing!
/Jon
>
> KC
>
> ---------------------------------------------------------
> Ken Cowan Thomson Software Products
> cowan@east.thomsoft.com 200 Wheeler Rd.
> phone: (617) 221-7323 Burlington, MA 01803
> fax: (617) 220-6882
--
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178
617.484.3383
jsa@organon.com
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Which compiler is correct??
1996-09-10 0:00 Which compiler is correct?? Robert B. Love
` (2 preceding siblings ...)
1996-09-11 0:00 ` Robert A Duff
@ 1996-09-11 0:00 ` Jon S Anthony
1996-09-12 0:00 ` Tucker Taft
4 siblings, 0 replies; 26+ messages in thread
From: Jon S Anthony @ 1996-09-11 0:00 UTC (permalink / raw)
In article <514uuu$d8i@uuneo.neosoft.com> rlove@neosoft.com (Robert B. Love ) writes:
> With Academic ObjectAda v7.0.171 I get 3 occurrences of the same error
> along with line and column numbers.
>
> LRM:6.4.15(5) If the mode is IN OUT or OUT, the actual
> shall be a name that denotes a variable.
Wow. Now, that's what I call an _excellent_ error message. I would
wager good money that if you stated where it was issued, we could
figure this out quickly. My guess is that it is at an invocation of
one of the routines in Ada.Exceptions since none of your subprograms
has any OUT/IN OUT mode parameters and the two "Get"s are passed
variables. But I'm not going to play compiler and try to find the
error location.
/Jon
--
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178
617.484.3383
jsa@organon.com
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Which compiler is correct??
1996-09-10 0:00 Which compiler is correct?? Robert B. Love
` (3 preceding siblings ...)
1996-09-11 0:00 ` Jon S Anthony
@ 1996-09-12 0:00 ` Tucker Taft
4 siblings, 0 replies; 26+ messages in thread
From: Tucker Taft @ 1996-09-12 0:00 UTC (permalink / raw)
Robert B. Love (rlove@neosoft.com) wrote:
: I've got a situation where I put the same piece of code thru two
: compilers on the same hardware and one will compile it, the other
: gives errors. The code is listed below and is taken from Richard
: Riehle's article in JOOP on "Managing Runtime Faults". GNAT compiles
: it fine. Aacademic ObjectAda fails to compile it.
: I can see maybe 4 choices: 1) GNAT is wrong, 2) ObjectAda is
: wrong, 3) the code is wrong, 4) I need to set some compile
: switches on one compiler or the other.
(1) and (3).
: On a PC with GNAT 304a touted as being compiled for Windows and
: GNAT 301 on a NeXT/M68040 I get no errors.
: With Academic ObjectAda v7.0.171 I get 3 occurrences of the same error
: along with line and column numbers.
:
: LRM:6.4.15(5) If the mode is IN OUT or OUT, the actual
: shall be a name that denotes a variable.
Aren't you going to tell us what lines and columns it identified???
: I need a language lawyer to tell me what is actually wrong.
Or the LRM ;-).
: Note I made 2 change to Riehle's article, commented with "my change"
: with ada.exceptions; use ada.exceptions;
: with text_io,ada.integer_text_io;use text_io;
: procedure exception_demo is
: error_list: array(1..3) of exception_occurrence;
: d1,d2,d3: integer;
: function square(data:integer) return integer is
: begin
: return data*data;
: exception
: when error_in_square_function:
: constraint_error => ada.exceptions.save_occurrence
: (error_in_square_function,error_list(1));
This looks like your problem. Procedure Save_Occurrence has two
parameters, the first is mode OUT, and the second is mode IN (RM95 11.4.1(6)).
"Error_In_Square_Function" is a constant (RM95 11.2(9)), so you can't pass
it to an OUT parameter. I suspect you meant to save the result
in error_list(1), so you will need to reverse the parameters, or
even better, use named notation (which is a good idea any time
there are two consecutive parameters of the same type, and the
operation isn't commutative).
Presumably the GNAT bug is that it doesn't consider a "choice parameter"
like "error_in_square_function" to be a constant, so it doesn't catch
your mistake. The same problem occurs in your other 2 calls on
Save_Occurrence.
I presume the line and column numbers given in the error message
pointed to the "error_in_square_function" operand.
..
: Bob Love, rlove@neosoft.com (local) MIME & NeXT Mail OK
: rlove@raptor.rmnug.org (permanent) PGP key available
-Tucker Taft stt@inmet.com http://www.inmet.com/~stt/
Intermetrics, Inc. Cambridge, MA USA
^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~1997-06-26 0:00 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-06-17 0:00 Which compiler is correct? Tom Moran
1997-06-18 0:00 ` Pascal Obry
1997-06-18 0:00 ` Tom Moran
1997-06-18 0:00 ` Robert A Duff
1997-06-18 0:00 ` John Woodruff
1997-06-19 0:00 ` Robert A Duff
1997-06-20 0:00 ` Jon S Anthony
1997-06-21 0:00 ` Robert A Duff
1997-06-26 0:00 ` Jon S Anthony
1997-06-19 0:00 ` Simon Wright
1997-06-20 0:00 ` Jon S Anthony
1997-06-21 0:00 ` Robert A Duff
1997-06-21 0:00 ` Robert A Duff
1997-06-21 0:00 ` Simon Wright
1997-06-23 0:00 ` Mats.Weber
1997-06-24 0:00 ` Jon S Anthony
-- strict thread matches above, loose matches on Subject: below --
1996-09-10 0:00 Which compiler is correct?? Robert B. Love
1996-09-10 0:00 ` Robert Dewar
1996-09-11 0:00 ` Robert B. Love
1996-09-10 0:00 ` Robert Dewar
1996-09-11 0:00 ` Robert A Duff
1996-09-12 0:00 ` Ken Cowan
1996-09-12 0:00 ` Ken Cowan
1996-09-13 0:00 ` Jon S Anthony
1996-09-11 0:00 ` Jon S Anthony
1996-09-12 0:00 ` Tucker Taft
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox