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=-1.9 required=5.0 tests=BAYES_00,WEIRD_PORT autolearn=ham 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 12:24:15 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!headwall.stanford.edu!news-out.nibble.net!news-in.nibble.net!newsfeed.direct.ca!look.ca!news1.tor.metronet.ca!nnrp1.tor.metronet.ca!not-for-mail Message-ID: <3B797ADE.4821C4A3@home.com> From: "Warren W. Gay VE3WWG" X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Ambiguous reference - What is wrong with this? References: <9lbf8n$brf$1@nh.pace.co.uk> <3B795848.9DAFEE53@home.com> <9lbokr$eog$1@nh.pace.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 14 Aug 2001 19:24:15 GMT NNTP-Posting-Host: 198.96.47.195 NNTP-Posting-Date: Tue, 14 Aug 2001 13:24:15 MDT Organization: MetroNet Communications Group Inc. Xref: archiver1.google.com comp.lang.ada:11932 Date: 2001-08-14T19:24:15+00:00 List-Id: Marin David Condic wrote: > 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. ... Clearly, argument 2 (Object2) is ambiguous between the 2 calls. Then the remaining issue is the Root.Base object's dispatching on Object, which can dispatch to Root.Base.Some_Proc() or Root.Child1.Some_Proc() depending upon the argument given in arg1 (Object). I think the problem is related to Object2 of Root.Some_Proc : Even though dispatching says Object1 should only accept Derive1 here, the classwide argument Object2 says that Root.Some_Proc is a first candidate, in addition to Root.Child1.Some_Proc. :< Warren. > 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. > > -- Warren W. Gay VE3WWG http://members.home.net/ve3wwg