comp.lang.ada
 help / color / mirror / Atom feed
* Is this a bug in Ada.Numerics?
@ 2012-10-21  0:37 Leo Brewin
  2012-10-21  1:54 ` Yannick Duchêne (Hibou57)
  2012-10-21  1:55 ` Ludovic Brenta
  0 siblings, 2 replies; 11+ messages in thread
From: Leo Brewin @ 2012-10-21  0:37 UTC (permalink / raw)


In the course of my dabblings in Ada I've come across a curious "behaviour" that seems to me, with my limited knowledge of Ada, to be a bug.

Here is a simple package spec

   with Ada.Numerics.Generic_Complex_Types;
   with Ada.Numerics.Generic_Complex_Elementary_Functions;

   package foo is

      type Real is digits 18;
		
      package Complex_Types is new
         Ada.Numerics.Generic_Complex_Types (Real);

      use foo.Complex_Types;
      -- subtype Complex is foo.Complex_Types.Complex;
      
      procedure bar (z : in out Complex);
   
   end foo;

and the package body

   package body foo is

      package Complex_Maths is new
         Ada.Numerics.Generic_Complex_Elementary_Functions (Complex_Types);
   
      procedure bar (z : in out Complex) is
      begin
         z := Complex'(Re(z),0.0);
      end bar;

   end foo;

As it stands this package compiles under GNAT GPL 2012. But if the "subtype" declaration in the package spec is un-commented then the compile fails with the following errors

04: instantiation error at a-ngcefu.ads:24
04: "Complex" is not visible (more references follow)
04: instantiation error at a-ngcefu.ads:24
04: non-visible declaration at foo.ads:11
04: instantiation error at a-ngcefu.ads:24
04: non-visible declaration at a-ngcoty.ads:42, instance at foo.ads:8
04: instantiation error at a-ngcefu.ads:24
04: non-visible declaration at a-ngcoty.ads:42, instance at a-ngcefu.ads:18

Is this behaviour correct? My limited understanding is that the "use foo.Complex_Types" should have made visible all types and operations on "Complex" and thus the extra "subtype" should be redundant and should not cause an error.

I've tried a few variations on the above and I found that if I
1) Comment out the "Package Complex_Maths" declaration, OR
2) Create a single procedure from the above package spec/body
then the code compiles happily with or without the "subtype" declaration.

If anybody could explain this behaviour to me I would be very grateful.

Cheers,
Leo



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Is this a bug in Ada.Numerics?
  2012-10-21  0:37 Is this a bug in Ada.Numerics? Leo Brewin
@ 2012-10-21  1:54 ` Yannick Duchêne (Hibou57)
  2012-10-21  2:39   ` Leo Brewin
  2012-10-21  1:55 ` Ludovic Brenta
  1 sibling, 1 reply; 11+ messages in thread
From: Yannick Duchêne (Hibou57) @ 2012-10-21  1:54 UTC (permalink / raw)


Hi,

Just reading your snippet (not tried to compile)

Le Sun, 21 Oct 2012 02:37:36 +0200, Leo Brewin  
<leo.brewin@internode.on.net> a écrit:

> In the course of my dabblings in Ada I've come across a curious  
> "behaviour" that seems to me, with my limited knowledge of Ada, to be a  
> bug.
>
> Here is a simple package spec
>
>    with Ada.Numerics.Generic_Complex_Types;
>    with Ada.Numerics.Generic_Complex_Elementary_Functions;
>
>    package foo is
>
>       type Real is digits 18;
> 		
>       package Complex_Types is new
>          Ada.Numerics.Generic_Complex_Types (Real);
>
>       use foo.Complex_Types;
>       -- subtype Complex is foo.Complex_Types.Complex;
>      procedure bar (z : in out Complex);
>   end foo;

When you do “use foo.Complex_Types;”, you introduce from then in the  
current scope, all definitions from “foo.Complex_Types”. (by the way, you  
don't need “use foo.Complex_Types;”, as “use Complex_Types;” would be  
enough). This means that “foo.Complex_Types.Complex” [1] is introduced in  
the scope, so there is a clash with the subtype you define right after.  
May be you did not understood what exactly “use” do?

[1] See [G.1.1 Complex  
Types](http://www.adaic.org/resources/add_content/standards/05rm/html/RM-G-1-1.html),  
which contains the following:

     type Complex is […]


> and the package body
>
>    package body foo is
>
>       package Complex_Maths is new
>          Ada.Numerics.Generic_Complex_Elementary_Functions  
> (Complex_Types);
>      procedure bar (z : in out Complex) is
>       begin
>          z := Complex'(Re(z),0.0);
>       end bar;
>
>    end foo;

Not part of the case, but here, you are instantiating a generic package  
which you don't use (must be an error).


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Is this a bug in Ada.Numerics?
  2012-10-21  0:37 Is this a bug in Ada.Numerics? Leo Brewin
  2012-10-21  1:54 ` Yannick Duchêne (Hibou57)
@ 2012-10-21  1:55 ` Ludovic Brenta
  2012-10-21  2:32   ` Leo Brewin
  1 sibling, 1 reply; 11+ messages in thread
From: Ludovic Brenta @ 2012-10-21  1:55 UTC (permalink / raw)


Leo Brewin writes on comp.lang.ada:
> In the course of my dabblings in Ada I've come across a curious
> "behaviour" that seems to me, with my limited knowledge of Ada, to be
> a bug.
>
> Here is a simple package spec
>
>    with Ada.Numerics.Generic_Complex_Types;
>    with Ada.Numerics.Generic_Complex_Elementary_Functions;
>
>    package foo is
>
>       type Real is digits 18;
> 		
>       package Complex_Types is new
>          Ada.Numerics.Generic_Complex_Types (Real);
>
>       use foo.Complex_Types;
>       -- subtype Complex is foo.Complex_Types.Complex;
>       
>       procedure bar (z : in out Complex);
>    
>    end foo;
>
> and the package body
>
>    package body foo is
>
>       package Complex_Maths is new
>          Ada.Numerics.Generic_Complex_Elementary_Functions (Complex_Types);
>    
>       procedure bar (z : in out Complex) is
>       begin
>          z := Complex'(Re(z),0.0);
>       end bar;
>
>    end foo;
>
> As it stands this package compiles under GNAT GPL 2012. But if the
> "subtype" declaration in the package spec is un-commented then the
> compile fails with the following errors
>
> 04: instantiation error at a-ngcefu.ads:24
> 04: "Complex" is not visible (more references follow)
> 04: instantiation error at a-ngcefu.ads:24
> 04: non-visible declaration at foo.ads:11
> 04: instantiation error at a-ngcefu.ads:24
> 04: non-visible declaration at a-ngcoty.ads:42, instance at foo.ads:8
> 04: instantiation error at a-ngcefu.ads:24
> 04: non-visible declaration at a-ngcoty.ads:42, instance at a-ngcefu.ads:18
>
> Is this behaviour correct? My limited understanding is that the "use
> foo.Complex_Types" should have made visible all types and operations
> on "Complex" and thus the extra "subtype" should be redundant and
> should not cause an error.

The file a-ngcefu.ads starts with:

with Ada.Numerics.Generic_Complex_Types;
generic
   with package Complex_Types is new Ada.Numerics.Generic_Complex_Types (<>);
   use Complex_Types;

package Ada.Numerics.Generic_Complex_Elementary_Functions is
   pragma Pure;

   function Sqrt (X : Complex)   return Complex; -- line 24

This last line, which causes all the error messages, involves the
subtype Complex.  The compiler tries to resolve this and finds two
possible solutions: Foo.Complex and Foo.Complex_Types.Complex, both of
which are directly visible.  Foo.Complex is directly visible because of
your use clause at foo.ads:11 and Foo.Complex_Types.Complex is directly
visible because of the use clause at a-ngcefu.ads:19.

The compiler cannot decide which subtype is meant, so it reports an
error.  I think the error is justified but the error message is cryptic.
A hint is:

> 04: non-visible declaration at a-ngcoty.ads:42, instance at foo.ads:8
> 04: non-visible declaration at a-ngcoty.ads:42, instance at a-ngcefu.ads:18

Since both subtypes are directly visible and clash, the compiler reports
both as non-visible :/

> I've tried a few variations on the above and I found that if I
> 1) Comment out the "Package Complex_Maths" declaration, OR
> 2) Create a single procedure from the above package spec/body
> then the code compiles happily with or without the "subtype"
> declaration.

You could try:

3) remove your "use Complex_Types" clause or move it to the body of your
procedure Bar.
4) remove your "subtype Foo.Complex is foo.Complex_Types.Complex"
altogether; why did you think you needed it?

> If anybody could explain this behaviour to me I would be very
> grateful.

You may think that Foo.Complex and Foo.Complex_Types.Complex are the
same thing.  They are not; they are two different subtypes of the same
type; they are declared in different packages and hence have different
scopes.  The fact that they have the same constraints is incidental and
irrelevant.  A relevant fact is that you are allowed to add
representation clauses (or aspects) to Foo.Complex, since you declared
it, but not to Foo.Complex_Types.Complex, since it is declared by (an
instance of) a standard package.

HTH

-- 
Ludovic Brenta.



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Is this a bug in Ada.Numerics?
  2012-10-21  1:55 ` Ludovic Brenta
@ 2012-10-21  2:32   ` Leo Brewin
  2012-10-21  3:39     ` Ludovic Brenta
  0 siblings, 1 reply; 11+ messages in thread
From: Leo Brewin @ 2012-10-21  2:32 UTC (permalink / raw)


Hi Ludovic,

Thanks for the quick and detailed response. Your suggestion (3) and (4) certainly do fix the problem but I was posing the original code (in its less than ideal form) as a way to understand how the compiler sorts out these scoping/visibility issues. In my real code I would do as you suggest.

But having digested your answer I'm still a bit confused (sorry). Here is the "procedure" version of the above package,

   with Ada.Numerics.Generic_Complex_Types;
   with Ada.Numerics.Generic_Complex_Elementary_Functions;

   procedure foo is

      type Real is digits 18;
		
      package Complex_Types is new 
         Ada.Numerics.Generic_Complex_Types (Real);

      use foo.Complex_Types;
      subtype Complex is foo.Complex_Types.Complex;
      
      procedure bar (z : in out Complex);
   
      package Complex_Maths is new 
         Ada.Numerics.Generic_Complex_Elementary_Functions (Complex_Types);
   
      procedure bar (z : in out Complex) is
      begin
         z := Complex'(Re(z),0.0);
      end bar;

   begin
      null;
   end foo;

This does compile and yet (by my reading of your reply) the "use foo" and "subtype complex" lines should introduce two distinct versions of Complex and thus should produce a compiler error.

I'm sure I've got this wrong, my apologies for wasting your time...

Cheers,
Leo



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Is this a bug in Ada.Numerics?
  2012-10-21  1:54 ` Yannick Duchêne (Hibou57)
@ 2012-10-21  2:39   ` Leo Brewin
  0 siblings, 0 replies; 11+ messages in thread
From: Leo Brewin @ 2012-10-21  2:39 UTC (permalink / raw)


On Sunday, October 21, 2012 12:54:35 PM UTC+11, Hibou57 (Yannick Duchêne) wrote:

> Not part of the case, but here, you are instantiating a generic package  
> 
> which you don't use (must be an error).

Hi Yannick,

Thanks for the quick reply. When I delete that unused package all of the errors I mention go away. You're right, the package is never used but its presence triggers the error I mentioned.

Cheers,
Leo



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Is this a bug in Ada.Numerics?
  2012-10-21  2:32   ` Leo Brewin
@ 2012-10-21  3:39     ` Ludovic Brenta
  2012-10-21  3:54       ` Leo Brewin
                         ` (3 more replies)
  0 siblings, 4 replies; 11+ messages in thread
From: Ludovic Brenta @ 2012-10-21  3:39 UTC (permalink / raw)


Leo Brewin <leo.brewin@internode.on.net> writes:
> But having digested your answer I'm still a bit confused (sorry). Here
> is the "procedure" version of the above package,
>
>    with Ada.Numerics.Generic_Complex_Types;
>    with Ada.Numerics.Generic_Complex_Elementary_Functions;
>
>    procedure foo is
>
>       type Real is digits 18;
> 		
>       package Complex_Types is new 
>          Ada.Numerics.Generic_Complex_Types (Real);
>
>       use foo.Complex_Types;
>       subtype Complex is foo.Complex_Types.Complex;
>       
>       procedure bar (z : in out Complex);
>    
>       package Complex_Maths is new 
>          Ada.Numerics.Generic_Complex_Elementary_Functions (Complex_Types);
>    
>       procedure bar (z : in out Complex) is
>       begin
>          z := Complex'(Re(z),0.0);
>       end bar;
>
>    begin
>       null;
>    end foo;
>
> This does compile and yet (by my reading of your reply) the "use foo"
> and "subtype complex" lines should introduce two distinct versions of
> Complex and thus should produce a compiler error.

The difference is that, in the procedure, the subtype Foo.Complex is
declared in the immediate scope where Complex_Maths is declared, so it
hides Foo.Complex_Types.Complex, so there is no ambiguity anymore.  You
get the same effect with the package if you move the declaration of
Complex_Maths to the package spec.

These rules are quite subtle and the error messages from GNAT less than
helpful.  Maybe that's why Ada has a reputation for being "difficult to
learn".

-- 
Ludovic Brenta.



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Is this a bug in Ada.Numerics?
  2012-10-21  3:39     ` Ludovic Brenta
@ 2012-10-21  3:54       ` Leo Brewin
  2012-10-21  8:59       ` Georg Bauhaus
                         ` (2 subsequent siblings)
  3 siblings, 0 replies; 11+ messages in thread
From: Leo Brewin @ 2012-10-21  3:54 UTC (permalink / raw)


Hi Ludovic,

Thank you, that makes sense. You've been very helpful (as many on CLA can attest :).

Yes, I agree, these rules are subtle but I'm determined to get on top of them. Hence the fiddling with little examples such as the above.

Cheers,
Leo



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Is this a bug in Ada.Numerics?
  2012-10-21  3:39     ` Ludovic Brenta
  2012-10-21  3:54       ` Leo Brewin
@ 2012-10-21  8:59       ` Georg Bauhaus
  2012-10-23 15:48       ` Vincent Marciante
  2012-10-23 22:52       ` Leo Brewin
  3 siblings, 0 replies; 11+ messages in thread
From: Georg Bauhaus @ 2012-10-21  8:59 UTC (permalink / raw)


On 21.10.12 05:39, Ludovic Brenta wrote:
> These rules are quite subtle and the error messages from GNAT less than
> helpful.  Maybe that's why Ada has a reputation for being "difficult to
> learn".

With GNAT, try adding

  -gnatwh turn on warnings for hiding declarations

(Perusing the list of compiler switches once in a while keeps being
very useful.)



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Is this a bug in Ada.Numerics?
  2012-10-21  3:39     ` Ludovic Brenta
  2012-10-21  3:54       ` Leo Brewin
  2012-10-21  8:59       ` Georg Bauhaus
@ 2012-10-23 15:48       ` Vincent Marciante
  2012-10-23 22:52       ` Leo Brewin
  3 siblings, 0 replies; 11+ messages in thread
From: Vincent Marciante @ 2012-10-23 15:48 UTC (permalink / raw)


"Ludovic Brenta" <ludovic@ludovic-brenta.org> wrote in message 
news:<87r4oscx42.fsf@ludovic-brenta.org>...

> Leo Brewin <leo.brewin@internode.on.net> writes:

> > But having digested your answer I'm still a bit confused (sorry). Here

> > is the "procedure" version of the above package,

> >

> >    with Ada.Numerics.Generic_Complex_Types;

> >    with Ada.Numerics.Generic_Complex_Elementary_Functions;

> >

> >    procedure foo is

> >

> >       type Real is digits 18;

> >

> >       package Complex_Types is new

> >          Ada.Numerics.Generic_Complex_Types (Real);

> >

> >       use foo.Complex_Types;

> >       subtype Complex is foo.Complex_Types.Complex;

> >

> >       procedure bar (z : in out Complex);

> >

> >       package Complex_Maths is new

> >          Ada.Numerics.Generic_Complex_Elementary_Functions 
> > (Complex_Types);

> >

> >       procedure bar (z : in out Complex) is

> >       begin

> >          z := Complex'(Re(z),0.0);

> >       end bar;

> >

> >    begin

> >       null;

> >    end foo;

> >

> > This does compile and yet (by my reading of your reply) the "use foo"

> > and "subtype complex" lines should introduce two distinct versions of

> > Complex and thus should produce a compiler error.

>

> The difference is that, in the procedure, the subtype Foo.Complex is

> declared in the immediate scope where Complex_Maths is declared, so it

> hides Foo.Complex_Types.Complex, so there is no ambiguity anymore.  You

> get the same effect with the package if you move the declaration of

> Complex_Maths to the package spec.

>

> These rules are quite subtle and the error messages from GNAT less than

> helpful.





This is a type of comment that AdaCore's Robert Dewar really likes to 
address.
I think that there is good chance that an improvement would be made in GNAT
to address this issue if you or the original poster send a report to 
AdaCore.



Vinny





> Maybe that's why Ada has a reputation for being "difficult to

> learn".

>

> -- 

> Ludovic Brenta.

. 





^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Is this a bug in Ada.Numerics?
  2012-10-21  3:39     ` Ludovic Brenta
                         ` (2 preceding siblings ...)
  2012-10-23 15:48       ` Vincent Marciante
@ 2012-10-23 22:52       ` Leo Brewin
  2012-10-23 23:09         ` Jeffrey Carter
  3 siblings, 1 reply; 11+ messages in thread
From: Leo Brewin @ 2012-10-23 22:52 UTC (permalink / raw)


Hi Ludovic,

I thought I was getting on top of this but then I ran a small experiment that doesn't make sense (to me).

I decided to make my own generic pacakges, ada_complex_types and ada_complex_functions, as clones of
Ada.Numerics.Generic_Complex_Types and 
Ada.Numerics.Generic_Complex_Elementary_Functions.

I had to add a couple of lines to the body of my packages, in particular I added these lines to
ada_complex_functions.adb

   Argument_Error : Excpetion;
   PI  : constant := 3.14159;
   
and this line to ada_complex_types.adb

   Argument_Error : Exception;

These changes were needed to allow compilation of the packages. Othe than the above small changes my generic packages are indetical to their Ada.Numerics counterparts.

I then used these pacakges in my previous example. I had expected no change in the errors reported by the compiler. But that is not what happens. I find that with or without the "subtype Complex ..." declaration the compiler reports no errors.

Am I missing something here?

Sorry to be a pain...

Cheers,
Leo




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Is this a bug in Ada.Numerics?
  2012-10-23 22:52       ` Leo Brewin
@ 2012-10-23 23:09         ` Jeffrey Carter
  0 siblings, 0 replies; 11+ messages in thread
From: Jeffrey Carter @ 2012-10-23 23:09 UTC (permalink / raw)


On 10/23/2012 03:52 PM, Leo Brewin wrote:
>
> Am I missing something here?

What you experienced is a compiler error and should be reported to AdaCore. The 
legality of a generic instantiation should not be affected by an unrelated 
subtype declaration elsewhere in the declarative part containing the instantiation.

-- 
Jeff Carter
"Pray that there's intelligent life somewhere up in
space, 'cause there's bugger all down here on earth."
Monty Python's Meaning of Life
61



^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2012-10-29  2:40 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-10-21  0:37 Is this a bug in Ada.Numerics? Leo Brewin
2012-10-21  1:54 ` Yannick Duchêne (Hibou57)
2012-10-21  2:39   ` Leo Brewin
2012-10-21  1:55 ` Ludovic Brenta
2012-10-21  2:32   ` Leo Brewin
2012-10-21  3:39     ` Ludovic Brenta
2012-10-21  3:54       ` Leo Brewin
2012-10-21  8:59       ` Georg Bauhaus
2012-10-23 15:48       ` Vincent Marciante
2012-10-23 22:52       ` Leo Brewin
2012-10-23 23:09         ` Jeffrey Carter

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox