Re: Ambiguous reference - What is wrong with this?

["Warren W. Gay VE3WWG" <ve3wwg@home.com>]

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" <ve3wwg@home.com> 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