Re: Ambiguous reference - What is wrong with this?

["Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org>]

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" <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.
>