Problem Compiling with GNAT

Problem Compiling with GNAT

[Larry]

First question:  How do you post to GNAT Chat?	I went to the ACT site, then
to GNAT Chat, and could see all the messages, but didn't see how to post.  I
think this post might be more appropriate there.

I have GNAT 3.11P on Windows NT 4.0 and am trying to compile a large amount
of Ada 83 code developed using Rational Apex.  We hope to port/re-develop the
code using GNAT.  This may not be enough information for anyone to diagnose
the problem but there is too much code to post it all and I just got it and
don't know it very well.

There is a type named Class in many packages and in one procedure the compiler
seems to be confused about which Class is used.  Here is abbreviated code for
that procedure:

procedure Display (Next_Timed_Fire_Mission     : in Fire_Missions.Class;
                   Next_Non_Timed_Fire_Mission : in Fire_Missions.Class) is

-- Fire_Missions.Class is a private record type.

   use Fire_Missions.Operators;
   Not_Used : Boolean;
begin

   if Next_Timed_Fire_Mission_Gui.Item_Of
      /= Next_Timed_Fire_Mission then
--    ^ Error messages point to this line
      Next_Timed_Fire_Mission_Gui.Set (Next_Timed_Fire_Mission);

      if Next_Timed_Fire_Mission = Fire_Missions.Null_Value then

            Display_This_Gui (This_Gui =>
                              Next_Timed_Fire_Mission_Gui.Clear_Display,
                              Continue => Not_Used);
      else
            Display_Next_Timed_Fire_Mission_Gui;
      end if;

   end if;
end Display;

This version gives the error messages:

  expected type "Location_Data.Class" defined at location_data.ads:100
  found type "Firing_Points.Class" defined at firing_points.ads:57

If I comment out the use Fire_Missions.Operators; statement, I get:

  operator for private type "Class" defined at fire_missions.ads:166
    is not directly visible
  use clause would make operation legal

I have also tried: not Fire_Missions."=" (...) without the use clause and I
get the first set of error messages.  I'm stumped.  Can anyone explain what
is happening?

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Problem Compiling with GNAT

[Matthew Heaney]

Larry <lhazel@mindspring.com> writes:

> There is a type named Class in many packages and in one procedure the
> compiler seems to be confused about which Class is used.  Here is
> abbreviated code for that procedure:

"Class" is a horrible choice for the name of a type.  Why don't you just
name the type "Fire_Mission"?

Re: Problem Compiling with GNAT

[Larry]

In article <m3sob6broj.fsf@mheaney.ni.net>,
  Matthew Heaney <matthew_heaney@acm.org> wrote:
> Larry <lhazel@mindspring.com> writes:
>
> > There is a type named Class in many packages and in one procedure the
> > compiler seems to be confused about which Class is used.  Here is
> > abbreviated code for that procedure:
>
> "Class" is a horrible choice for the name of a type.  Why don't you just
> name the type "Fire_Mission"?
>
I agree.  I inherited this code, don't understand it yet, and am trying to get
as much of it to compile as possible with minimum changes.  Actually,
Fire_Mission is the name of one package in which a type Class is defined.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Problem Compiling with GNAT

[fraser]

paene lacrimavi postquam Larry <lhazel@mindspring.com> scribavit:

>In article <m3sob6broj.fsf@mheaney.ni.net>,

>> "Class" is a horrible choice for the name of a type.  Why don't you just
>> name the type "Fire_Mission"?

>I agree.  I inherited this code, don't understand it yet, and am trying to get
>as much of it to compile as possible with minimum changes.  Actually,
>Fire_Mission is the name of one package in which a type Class is defined.

I remember reading somewhere (might have been an article on adahome,
can't remember) about a coding, uh, paradigm for want of a better word,
which created a class hierarchy using child pacakages to define names,
and having exactly one tagged type per (leaf) child package, which is
always called 'Object' or 'Class' or 'Instance' or whatever.

I tried it and didn't like it (and I didn't inhale either).  However,
what I've found lately is that the idea of defining exactly one tagged
type in each package seems valuable.  It makes packages small, and
maintenance easier.  Well, it has so far.  We'll see.

Fraser.
(change i's to y's to get my real email address)

Re: Problem Compiling with GNAT

[Matthew Heaney]

fraser@sinopsis.com writes:

> I tried it and didn't like it (and I didn't inhale either).  However,
> what I've found lately is that the idea of defining exactly one tagged
> type in each package seems valuable.  It makes packages small, and
> maintenance easier.  Well, it has so far.  We'll see.

For some coding ideas, you can search the ACM patterns archive starting
in Oct/Nov 98, and continuing to the present.

<http://www.acm.org/archives/patterns.html>

You can subscribe to the patterns list by sending the message (body)

subscribe patterns <your full name>

to the ACM mailing-list server.

<mailto:listserv@acm.org>

Matt

Re: Problem Compiling with GNAT

[Jean-Pierre Rosen]

fraser@sinopsis.com a �crit dans le message
<7ck8pk$2co$1@remarQ.com>...
>paene lacrimavi postquam Larry <lhazel@mindspring.com> scribavit:
>I remember reading somewhere (might have been an article on adahome,
>can't remember) about a coding, uh, paradigm for want of a better
word,
>which created a class hierarchy using child pacakages to define
names,
>and having exactly one tagged type per (leaf) child package, which is
>always called 'Object' or 'Class' or 'Instance' or whatever.
>
The paper is called "A naming convention for classes in Ada 9X", and
appeared in Ada Letters, Vol. XV, n�2, by (hum) J-P. Rosen.

I agree that the notation may seem odd in isolation. However, it is
easy to enforce, shows which type is the "main" type in a package, and
is consistent with the fact that a "class" in Ada is not a type, but a
package used in a certain way.
Moreover (and foremost), it is the only convention I could find which
is consistent when you use "facet" generic packages, i.e. packages
that create new tagged types from imported ones.
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://perso.wanadoo.fr/adalog

Re: Problem Compiling with GNAT

[Larry]

In article <7cj6nt$rvh$1@nnrp1.dejanews.com>,
  Larry <lhazel@mindspring.com> wrote:

> There is a type named Class in many packages and in one procedure the compiler
> seems to be confused about which Class is used.  Here is abbreviated code for
> that procedure:
>
> procedure Display (Next_Timed_Fire_Mission     : in Fire_Missions.Class;
>                    Next_Non_Timed_Fire_Mission : in Fire_Missions.Class) is
>
> -- Fire_Missions.Class is a private record type.
>
>    use Fire_Missions.Operators;
>    Not_Used : Boolean;
> begin
>
>    if Next_Timed_Fire_Mission_Gui.Item_Of
>       /= Next_Timed_Fire_Mission then
> --    ^ Error messages point to this line
>       Next_Timed_Fire_Mission_Gui.Set (Next_Timed_Fire_Mission);
>
>       if Next_Timed_Fire_Mission = Fire_Missions.Null_Value then
>
>             Display_This_Gui (This_Gui =>
>                               Next_Timed_Fire_Mission_Gui.Clear_Display,
>                               Continue => Not_Used);
>       else
>             Display_Next_Timed_Fire_Mission_Gui;
>       end if;
>
>    end if;
> end Display;
>
> This version gives the error messages:
>
>   expected type "Location_Data.Class" defined at location_data.ads:100
>   found type "Firing_Points.Class" defined at firing_points.ads:57
>
> If I comment out the use Fire_Missions.Operators; statement, I get:
>
>   operator for private type "Class" defined at fire_missions.ads:166
>     is not directly visible
>   use clause would make operation legal

This has generated some good discussion but no answers yet.  I got an email
from Robert Dewar "strongly" suggesting support from ACT and I'm working on
that but it's not going to happen quickly.

If you look at the error messages, you will see that the compiler finds the
correct "Class" for the comparison without the use clause but finds 2 other
types with the use clause.  This is what has me confused.

It is now even more confusing.	I edited all definitions and references to
Fire_Missions.Class to be Fire_Missions.Claxx.	There was no change in the
error messages other than the name change in the second set.  With the use
clause, GNAT still complains about "Location_Data.Class" and
"Firing_Points.Class".

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Problem Compiling with GNAT

[Matthew Heaney]

"Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes:

> I agree that the notation may seem odd in isolation. 

It is odd all the time, Jean-Pierre.

> Moreover (and foremost), it is the only convention I could find which
> is consistent when you use "facet" generic packages, i.e. packages
> that create new tagged types from imported ones.

Just because "it is the only convention you could find which is
consistent" does not mean that another such convention does not exist!  

Re: Problem Compiling with GNAT

[Brian Rogoff]

On 16 Mar 1999 fraser@sinopsis.com wrote:
> paene lacrimavi postquam Larry <lhazel@mindspring.com> scribavit:
> 
> >In article <m3sob6broj.fsf@mheaney.ni.net>,
> 
> >> "Class" is a horrible choice for the name of a type.  Why don't you just
> >> name the type "Fire_Mission"?
> 
> >I agree.  I inherited this code, don't understand it yet, and am trying to get
> >as much of it to compile as possible with minimum changes.  Actually,
> >Fire_Mission is the name of one package in which a type Class is defined.
> 
> I remember reading somewhere (might have been an article on adahome,
> can't remember) about a coding, uh, paradigm for want of a better word,
> which created a class hierarchy using child pacakages to define names,
> and having exactly one tagged type per (leaf) child package, which is
> always called 'Object' or 'Class' or 'Instance' or whatever.
> 
> I tried it and didn't like it (and I didn't inhale either).  However,
> what I've found lately is that the idea of defining exactly one tagged
> type in each package seems valuable.  It makes packages small, and
> maintenance easier.  Well, it has so far.  We'll see.

One thing I'm trying, and liking, is the Modula-3/OCaml naming style like
so 

package Lists is 
    type T is ...;          -- Main type is always "T"
    type Iterator_T is ...; -- Subordinate types named "<Something>_T"
...

which is similar to the "Class" style. This goes part of the way to the 
one (tagged) type per package style, but acknowledges that you may want to 
declare some helper types too. I believe I can get used to just about any 
consistent coding style, and this one has the virtue of being terse,
especially when wielded by anti-"use" fanatics :-).

-- Brian

Re: Problem Compiling with GNAT

[Fraser Wilson]

paene lacrimavi postquam Jean-Pierre Rosen scribavit:

>I agree that the notation may seem odd in isolation. However, it is
>easy to enforce, shows which type is the "main" type in a package, and
>is consistent with the fact that a "class" in Ada is not a type, but a
>package used in a certain way.

Well, that was probably the problem I had.  At the time I was picking
coding styles pseudo-randomly, until I found one that fit.  It tends to
make the result somewhat, well, mish-mashed.

>Moreover (and foremost), it is the only convention I could find which
>is consistent when you use "facet" generic packages, i.e. packages
>that create new tagged types from imported ones.

I'm not sure I understand this --- what you're saying is that the generic
can't possibly provide a meaningful type name, because unlike a standard
type that's declared in a generic package, the generic itself doesn't
know exactly what the type is going to do; it merely adds some functionality
to it.  In this case, fair call.

Fraser.
(change i's to y's for my real email address)