GNAT Problem on recursive generics?

GNAT Problem on recursive generics?

[Debora Weber-Wulff]

Ran into this problem in GNAT 3.05 using the IDE on a PC the other
day:


-- foo.ads
generic
   type element is (<>);
procedure foo (e: in out element);

-- foo.adb
procedure foo (e: in out element) is
   begin
   if 1=1 then
     foo(element'pred(e));
   else
     foo(element'succ(e));
end if;
end foo;

-- foo.lsb

GNAT 3.05 (960607) Copyright 1991-1996 Free Software Foundation, Inc.

Compiling: foo.adb (source file time stamp: 1996-11-27 16:17:58)

     1. procedure foo (e: in out element) is
     2.    begin
     3.    if 1=1 then
     4.      foo(element'pred(e));
	     |
	>>> "foo" is not visible (more references follow)
	>>> non-visible declaration at foo.ads:3

     5. else
     6.     foo(element'succ(e));
     7. end if;
     8. end foo;

 8 lines:

According to the LRM for Ada 95, a recursive call is permitted in a
generic unit (I think, I'm not a practicing language lawyer). 

We found a work-around by putting foo in a generic *package* bar
that has the same generic parameters as foo needed. Works like a charm :-)

Is this something I don't understand or a GNAT problem? 
[I know that this belongs in some gnat-errors mailing list, but I?ve
looked and can't find the address. Happens often recently. I know there
is a group for this or that, but can't remember where I wrote down
the reference...]

--
Debora Weber-Wulff (Professorin fuer Softwaretechnik und Programmiersprachen)
Technische Fachhochschule Berlin, FB Informatik, Luxemburger Str. 10, 
13353 Berlin, Germany        email: weberwu@tfh-berlin.de   
<http://www.tfh-berlin.de/~weberwu/> 

Re: GNAT Problem on recursive generics?

[Robert Dewar]

Debora asks about

GNAT 3.05 (960607) Copyright 1991-1996 Free Software Foundation, Inc.

Compiling: foo.adb (source file time stamp: 1996-11-27 16:17:58)

     1. procedure foo (e: in out element) is
     2.    begin
     3.    if 1=1 then
     4.      foo(element'pred(e));
             |
        >>> "foo" is not visible (more references follow)


Well clearly this program is wrong, since foo has an in out parameter,
and of course you cannot pass an expression like this, only a variable.

However, the GNAT error message is certainly confusing, you did not
say which version of GNAT you are using (remember that saying PC is
not enough, GNAT is ported to nine different operating systems on the
PC), but in any case the latest version of GNAT gives the clearer
error messages:

     2. -- foo.adb
     3. procedure foo (e: in out element) is
     4.    begin
     5.    if 1=1 then
     6.      foo(element'pred(e));
                        |
        >>> actual for "e" must be a variable

     7.    else
     8.      foo(element'succ(e));
                        |
        >>> actual for "e" must be a variable

     9. end if;
    10. end foo;


remember in future, if you find what you think is a bug in GNAT, be sure
to submit it with complete sources, following the directions in gnatinfo.txt,
to report@gnat.com if you want the GNAT folks to look at it!

Re: GNAT Problem on recursive generics?

[Ray Blaak]

Recursion is certainly allowable. The problem is something else: e is "in out",
but you are passing in a function result ('pred or 'succ) which is a constant.
GNAT (correctly) does no find any foo with that profile.

Either change e to "in", or assign to a variable before calling foo again.

Cheers,
Ray Blaak
blaak@mda.ca

weberwu@compute.tfh-berlin.de (Debora Weber-Wulff) writes:

>Ran into this problem in GNAT 3.05 using the IDE on a PC the other
>day:

>-- foo.adb
>procedure foo (e: in out element) is
>   begin
>   if 1=1 then
>     foo(element'pred(e));
>   else
>     foo(element'succ(e));
>end if;
>end foo;
>	>>> "foo" is not visible (more references follow)
>	>>> non-visible declaration at foo.ads:3

Re: GNAT Problem on recursive generics?

[Debora Weber-Wulff]

Of course, you all are right, I oversimplified there. When I now do

procedure foo (e:element) is
 e1, e2:element;
begin
 if 1=1 then
    foo (e1);
 else
    foo (e2);
 end if;
end foo;

I still get the same visibility error. It goes away when I enclose
this in a package. I will try and get a gnatified version of the
error put together for report@gnat.com
  

Thanks for giving the
the gnat error-report address. I have no idea where the gnatinfo.txt
is, as I did not install the software, but I will look for it.
--
Debora Weber-Wulff (Professorin fuer Softwaretechnik und Programmiersprachen)
Technische Fachhochschule Berlin, FB Informatik, Luxemburger Str. 10, 
13353 Berlin, Germany        email: weberwu@tfh-berlin.de   
<http://www.tfh-berlin.de/~weberwu/> 

Re: GNAT Problem on recursive generics?

[Robert Dewar]

Debora says

"Thanks for giving the
the gnat error-report address. I have no idea where the gnatinfo.txt
is, as I did not install the software, but I will look for it."


Please try to read the documentation if you are using GNAT, you will be
surprised how much useful information is there :-)
Also note that 3.07 releases contain the initial versions of the full
GNAT manuals, with even more interesting information.

As for the bug here, the latest post is of course incomplete, so it is
impossible to tell anything. It's always possible there is a GNAT bug,
but so far nothing you posted backs up that assumption :-)