Re: Is this a bug in Ada.Numerics?

[Ludovic Brenta <ludovic@ludovic-brenta.org>]

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.