Ada question: access types

Ada question: access types

[Norman Reich]

Hi!  I am a new user to Ada (about 2 weeks), and new to
this newsgroup as well (about 2 minutes).  It was suggested
that I try out this newsgroup to seek help with a problem
that I was having.  I hope that I'm not misuing the group.
Anyway, here is my question:

I am using an IBM PS/2 with Meridian Ada, although I don't
think what I'm doing should be compiler dependent.

NOTE: Everything below is simplified to get my point across.

I have the following definitions:

     TYPE ptr IS ACCESS node;
     TYPE node IS
       RECORD
         name ...
         ...
         nextn :ptr;
       END RECORD;

     nl :ptr;

Within the program, I am doing a comparison, to see if the
list is empty or not:

     if (nl = NULL) then          --error at this line
     ...

The compiler is then giving me the following error at the
line above:

     type clash in parameter to "="

I have no idea why it would be doing this, and in examples
I have seen similar things done.  If anybody has any suggestions
that would be helpful, I would really appreciate it.

Thanks.

- Norman Reich
  nreich@seas.gwu.edu
  (301) 937-4858

Re: Ada question: access types

[Alex Blakemore]

In article <1992Oct4.211734.9047@seas.gwu.edu> nreich@seas.gwu.edu (Norman Reic
h) writes:

Assume
package my_types is

>      TYPE ptr IS ACCESS node;
>      TYPE node IS
>        RECORD
>          name ...
>          ...
>          nextn :ptr;
>        END RECORD;
>      nl :ptr;

and in another library unit 
>      if (nl = NULL) then          --error at this line
>      type clash in parameter to "="

type ptr is probably in a different package than the if statement.
you probably made type ptr visible via a with clause and did not
make it _directly_ visible via a use clause.  this is probably the
most common "error" new users hit and Ada9X is more forgiving here.
The error message could be better though.

Remember the function "=" (left, right : ptr) is implicitly
defined just after the definition of type ptr.

Your choices are:
a. invoke "=" using dotted infix notation.
   if my_types."=" (nl, null) then
b. make my_types."=" directly visible by adding a use clause.
   use my_types;
c. rename my_types."=" to make it directly visible
   function "=" (left, right : my_types.ptr) renames my_types."=";
-- 
---------------------------------------------------
Alex Blakemore alex@cs.umd.edu   NeXT mail accepted

Re: Ada question: access types

[Kevin Simonson]

     In article <60887@mimsy.umd.edu> alex@cs.umd.edu (Alex Blakemore) writes:

=In article <1992Oct4.211734.9047@seas.gwu.edu> nreich@seas.gwu.edu (Norman
=Reich) writes:
=
=Assume
=package my_types is
=
=>      TYPE ptr IS ACCESS node;
=>      TYPE node IS
=>        RECORD
=>          name ...
=>          ...
=>          nextn :ptr;
=>        END RECORD;
=>      nl :ptr;
=
=and in another library unit 
=>      if (nl = NULL) then          --error at this line
=>      type clash in parameter to "="
=
=type ptr is probably in a different package than the if statement.
=you probably made type ptr visible via a with clause and did not
=make it _directly_ visible via a use clause.

     This is probably the problem, but let me also note that after copying
exactly what Norman had written into a _single_ file, I got nearly the
same error message he was talking about.

     My compiler (Verdix) told me:

   if (nl = NULL) then
---------#^#
-- error: RM 4.5: does not conform to any visible operator              #^#

which sounded similar to the error message Norman got.

     However, earlier in my code I also got the message:

   TYPE ptr IS ACCESS node;
---------------------#^#
-- error: RM 8.3: identifier undefined                                  #^#

     Apparently if "nl" is defined as a type that the compiler doesn't un-
derstand, then it concludes that the type of "nl" doesn't match with
"NULL".  I added

   type node;

earlier in the program and it compiled just fine.  Norman, you might check
your code to make sure you referred to type "node" before the line that de-
fined "ptr".

                                     ---Kevin