From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00, WEIRD_PORT autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d58fe1ff04da7fd7 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-08-14 11:05:08 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!psinet-eu-nl!psiuk-p4!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: Ambiguous reference - What is wrong with this? Date: Tue, 14 Aug 2001 13:54:32 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9lbokr$eog$1@nh.pace.co.uk> References: <9lbf8n$brf$1@nh.pace.co.uk> <3B795848.9DAFEE53@home.com> NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 997811675 15120 136.170.200.133 (14 Aug 2001 17:54:35 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 14 Aug 2001 17:54:35 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:11930 Date: 2001-08-14T17:54:35+00:00 List-Id: Thanks for the test. At least that implies that it probably isn't a compiler bug. I think the compiler points at the type declaration because that is the point at which all the inherited operations enter into the picture. It unfortunately is not more specific - pointing to the exact procedures in the other packages that it is in conflict with - although one can easily guess. :-) The wierdness to me seems to be coming from the fact that I explicitly identified the procedure I wanted. Only probably because the names and the profiles are somehow considered identical and allowing for dispatching, maybe it means they aren't any different. Sort of a recursion that can't be terminated. The idea I was working on is to have some root class from which I start deriving. One branch of the tree evolves lists of various types while the other branch evolves data with various characteristics that are useful to have. What would happen is that I create a list type that can store anything derived from the root object (including another list), then evolve that to a list that can be sorted because the only objects that can get on it are derived from a child type requiring comparison operations (ordinal data). This eventually evolves to a list that can have statistics accumulated on it because the data items that can get on it must be derived from a child type that requires math operations (scalar data). And so on down the chain. In each case, you have a package with a specific list type and a 'Class wide element type because you need abstract types to describe ordinal and scalar data that hasn't been determined yet. (Deriving from the ordinal class you could have integer or string or enumerated data - so long as comparisons could be defined. Similarly from the scalar parent you could derive integer, real or even set or matrix data provided you could define appropriate math operators.) Maybe I could change the parameters to not be class-wide? But then, I'd have to have non-abstract parents for the ordinal or scalar data. Hmmmmmmmm...... Its a kind of experiment, so I'm not exactly married to the specific implementation. If you have an alternate scheme to try, I'm willing to take a shot at it. But I do think its important to this experiment that everything come from a single root type so all the descendent objects share some common properties and can be treated alike in some respects. (Heterogeneous lists, etc.) I'll entertain any ideas anyone has on this subject. Thanks. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Warren W. Gay VE3WWG" wrote in message news:3B795848.9DAFEE53@home.com... > > I tried this out under HPUX 11.0, using gnat 3.12p, and got precisely > the same results.. > > Your code looks to me like it should compile OK, and in fact I was expecting > to use the same technique someday soon. But maybe my understanding of this > situation is not complete. > > It seems that the compiler is confused between the Base > object's Root.Some_Proc procedure, and the Root.Child1.Some_Proc, > because of the message : > > root-child1-child2.adb:15:20: possible interpretation at root-child1.ads:3 > > which seems odd. Line 3 is singled out in the message where you > derive the type from Base. > > This to me does not make sense, since all seems to be pretty clear > about what the dispatch should be. I even made all of your tagged > records non-private, and got the same results. > > I guess I can't help, or its a bug. > > Good luck, Warren. >