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