Which compiler is correct?

Which compiler is correct?

[Tom Moran]

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;

Re: Which compiler is correct?

[Robert A Duff]

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

Re: Which compiler is correct?

[John Woodruff]

>>>>> "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 \

Re: Which compiler is correct?

[Robert A Duff]

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

Re: Which compiler is correct?

[Jon S Anthony]

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

Re: Which compiler is correct?

[Robert A Duff]

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

Re: Which compiler is correct?

[Jon S Anthony]

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

Re: Which compiler is correct?

[Simon Wright]

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

Re: Which compiler is correct?

[Jon S Anthony]

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

Re: Which compiler is correct?

[Robert A Duff]

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

Re: Which compiler is correct?

[Robert A Duff]

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

Re: Which compiler is correct?

[Simon Wright]

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

Re: Which compiler is correct?

[Mats.Weber]

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

Re: Which compiler is correct?

[Jon S Anthony]

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

Re: Which compiler is correct?

[Pascal Obry]

[-- 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"

Re: Which compiler is correct?

[Tom Moran]

> It seem to me that compiler G (GNAT) and J (Janus ???) are corrects
> and that compiler O (ObjectAda) is wrong.
  It seems that way to me too, but having experienced G & J & I being
wrong and O right, I thought I'd ask on c.l.a.

Which compiler is correct??

[Robert B. Love]

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
----------------------------------------------------------------

Re: Which compiler is correct??

[Robert Dewar]

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 :-)

Re: Which compiler is correct??

[Robert B. Love]

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
----------------------------------------------------------------

Re: Which compiler is correct??

[Robert Dewar]

"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!

Re: Which compiler is correct??

[Robert A Duff]

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

Re: Which compiler is correct??

[Ken Cowan]

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

Re: Which compiler is correct??

[Ken Cowan]

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

Re: Which compiler is correct??

[Jon S Anthony]

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

Re: Which compiler is correct??

[Jon S Anthony]

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

Re: Which compiler is correct??

[Tucker Taft]

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