GNAT Problem on recursive generics? 
Author Message
 GNAT Problem on recursive generics?

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,

< http://www.*-*-*.com/ ~weberwu/>



Tue, 18 May 1999 03:00:00 GMT  
 GNAT Problem on recursive generics?

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,



Thu, 20 May 1999 03:00:00 GMT  
 GNAT Problem on recursive generics?

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

Quote:

>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



Fri, 21 May 1999 03:00:00 GMT  
 GNAT Problem on recursive generics?

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

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,

<http://www.tfh-berlin.de/~weberwu/>



Sat, 22 May 1999 03:00:00 GMT  
 GNAT Problem on recursive generics?

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



Sat, 22 May 1999 03:00:00 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. recursive types and generics

2. Debugging Generics with GNAT 3.07

3. Ada generics / GNAT Heap-sort

4. generics defined in terms of generics?

5. generics using generics (long)

6. Recursive to tail recursive definitions...???

7. Problem trying to implement generics.

8. ASIS problem with generics (Long)

9. Compute generics problem

10. knotty generics problem

11. Recursive or quasi-recursive calls

12. head recursive or tail recursive

 

 
Powered by phpBB® Forum Software