Ambiguous reference - What is wrong with this?

Ambiguous reference - What is wrong with this?

[Marin David Condic]

O.K. I've got a compilation problem that is most likely due to my
misunderstanding of some language rule. Below is some code that shows a
simplified version of the problem. I'm using Gnat 3.13p on a WinNT PC.

I'm pretty sure that the problem has something to do with the 'Class
parameters creating some kind of ambiguity - but given that I've fully
qualified the names, it seems like the compiler ought to know which
procedure I meant to call. The quest6ion is twofold: Am I doing something
illegal (if so, what?) and if it *is* illegal, then is there an alternate
way of doing essentially the same thing? (One parameter being of a specific
descendent and the other being a class-wide parameter. The class wide
parameter wants to be an increasingly restrictive subset as you move down
the chain of child packages)

package Root is
    type Base is tagged private ;
    procedure Some_Proc (
        Object         : in out Base;
        Object2        : in out Base'Class) ;
private
    type Base is tagged record
        Data_Item_1    : Natural    := 0 ;
    end record ;
end Root ;

package body Root is
    procedure Some_Proc (
        Object         : in out Base;
        Object2        : in out Base'Class) is
    begin
        null ;
    end Some_Proc ;
end Root ;

package Root.Child1 is
    type Derive1 is new Base with private ;
    procedure Some_Proc (
        Object         : in out Derive1;
        Object2        : in out Derive1'Class) ;
private
    type Derive1 is new Base with record
        Data_Item_2    : Natural    := 0 ;
    end record ;
end Root.Child1 ;

package body Root.Child1 is
    procedure Some_Proc (
        Object         : in out Derive1;
        Object2        : in out Derive1'Class) is
    begin
        Root.Some_Proc (
            Object     => Root.Base (Object),
            Object2    => Object2) ;
    end Some_Proc ;
end Root.Child1 ;

package Root.Child1.Child2 is
    type Derive2 is new Derive1 with private ;
    procedure Some_Proc (
        Object         : in out Derive2;
        Object2        : in out Derive2'Class) ;
private
    type Derive2 is new Derive1 with record
        Data_Item_3    : Natural    := 0 ;
    end record ;
end Root.Child1.Child2 ;

package body Root.Child1.Child2 is
    procedure Some_Proc (
        Object         : in out Derive2;
        Object2        : in out Derive2'Class) is
    begin
        --
        --    Dies here with the following error message:
        --
        --    root-child1-child2.adb:15:20: ambiguous expression (cannot
resolve "Some_Proc")
        --    root-child1-child2.adb:15:20: possible interpretation at
root-child1.ads:4
        --    root-child1-child2.adb:15:20: possible interpretation at
root-child1.ads:3
        --    gnatmake: "root-child1-child2.adb" compilation error
        --
        Root.Child1.Some_Proc (
            Object     => Root.Child1.Derive1 (Object),
            Object2    => Object2) ;
    end Some_Proc ;
end Root.Child1.Child2 ;

Thanks for any help you can offer.

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/

Re: Ambiguous reference - What is wrong with this?

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
> 
> O.K. I've got a compilation problem that is most likely due to my
> misunderstanding of some language rule. Below is some code that shows a
> simplified version of the problem. I'm using Gnat 3.13p on a WinNT PC.

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.

> I'm pretty sure that the problem has something to do with the 'Class
> parameters creating some kind of ambiguity - but given that I've fully
> qualified the names, it seems like the compiler ought to know which
> procedure I meant to call. The quest6ion is twofold: Am I doing something
> illegal (if so, what?) and if it *is* illegal, then is there an alternate
> way of doing essentially the same thing? (One parameter being of a specific
> descendent and the other being a class-wide parameter. The class wide
> parameter wants to be an increasingly restrictive subset as you move down
> the chain of child packages)
> 
> package Root is
>     type Base is tagged private ;
>     procedure Some_Proc (
>         Object         : in out Base;
>         Object2        : in out Base'Class) ;
> private
>     type Base is tagged record
>         Data_Item_1    : Natural    := 0 ;
>     end record ;
> end Root ;
> 
> package body Root is
>     procedure Some_Proc (
>         Object         : in out Base;
>         Object2        : in out Base'Class) is
>     begin
>         null ;
>     end Some_Proc ;
> end Root ;
> 
> package Root.Child1 is
>     type Derive1 is new Base with private ;
>     procedure Some_Proc (
>         Object         : in out Derive1;
>         Object2        : in out Derive1'Class) ;
> private
>     type Derive1 is new Base with record
>         Data_Item_2    : Natural    := 0 ;
>     end record ;
> end Root.Child1 ;
> 
> package body Root.Child1 is
>     procedure Some_Proc (
>         Object         : in out Derive1;
>         Object2        : in out Derive1'Class) is
>     begin
>         Root.Some_Proc (
>             Object     => Root.Base (Object),
>             Object2    => Object2) ;
>     end Some_Proc ;
> end Root.Child1 ;
> 
> package Root.Child1.Child2 is
>     type Derive2 is new Derive1 with private ;
>     procedure Some_Proc (
>         Object         : in out Derive2;
>         Object2        : in out Derive2'Class) ;
> private
>     type Derive2 is new Derive1 with record
>         Data_Item_3    : Natural    := 0 ;
>     end record ;
> end Root.Child1.Child2 ;
> 
> package body Root.Child1.Child2 is
>     procedure Some_Proc (
>         Object         : in out Derive2;
>         Object2        : in out Derive2'Class) is
>     begin
>         --
>         --    Dies here with the following error message:
>         --
>         --    root-child1-child2.adb:15:20: ambiguous expression (cannot
> resolve "Some_Proc")
>         --    root-child1-child2.adb:15:20: possible interpretation at
> root-child1.ads:4
>         --    root-child1-child2.adb:15:20: possible interpretation at
> root-child1.ads:3
>         --    gnatmake: "root-child1-child2.adb" compilation error
>         --
>         Root.Child1.Some_Proc (
>             Object     => Root.Child1.Derive1 (Object),
>             Object2    => Object2) ;
>     end Some_Proc ;
> end Root.Child1.Child2 ;
> 
> Thanks for any help you can offer.
> 
> 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
http://members.home.net/ve3wwg

Re: Ambiguous reference - What is wrong with this?

[Warren W. Gay VE3WWG]

Replying further to this post with new information..

"Warren W. Gay VE3WWG" wrote:
> 
> Marin David Condic wrote:
> >
> > O.K. I've got a compilation problem that is most likely due to my
> > misunderstanding of some language rule. Below is some code that shows a
> > simplified version of the problem. I'm using Gnat 3.13p on a WinNT PC.

The AONIX compiler faults the same lines, with the message:

... LRM 8.6(31) Ambiguous call, possible definitions of Some_Proc appear at
line 3 of root-child1.ads, line 4 (same file).

I havn't had time to look at this in detail yet, but LRM 8.6 reports:

8.6 The Context of Overload Resolution

(31)
     A complete context other than a pragma_argument_association shall 
     not be ambiguous. 

I'd have to study this whole section to make sense of this error.

Good luck, Warren.

> > I'm pretty sure that the problem has something to do with the 'Class
> > parameters creating some kind of ambiguity - but given that I've fully
> > qualified the names, it seems like the compiler ought to know which
> > procedure I meant to call. The quest6ion is twofold: Am I doing something
> > illegal (if so, what?) and if it *is* illegal, then is there an alternate
> > way of doing essentially the same thing? (One parameter being of a specific
> > descendent and the other being a class-wide parameter. The class wide
> > parameter wants to be an increasingly restrictive subset as you move down
> > the chain of child packages)
> >
> > package Root is
> >     type Base is tagged private ;
> >     procedure Some_Proc (
> >         Object         : in out Base;
> >         Object2        : in out Base'Class) ;
> > private
> >     type Base is tagged record
> >         Data_Item_1    : Natural    := 0 ;
> >     end record ;
> > end Root ;
> >
> > package body Root is
> >     procedure Some_Proc (
> >         Object         : in out Base;
> >         Object2        : in out Base'Class) is
> >     begin
> >         null ;
> >     end Some_Proc ;
> > end Root ;
> >
> > package Root.Child1 is
> >     type Derive1 is new Base with private ;
> >     procedure Some_Proc (
> >         Object         : in out Derive1;
> >         Object2        : in out Derive1'Class) ;
> > private
> >     type Derive1 is new Base with record
> >         Data_Item_2    : Natural    := 0 ;
> >     end record ;
> > end Root.Child1 ;
> >
> > package body Root.Child1 is
> >     procedure Some_Proc (
> >         Object         : in out Derive1;
> >         Object2        : in out Derive1'Class) is
> >     begin
> >         Root.Some_Proc (
> >             Object     => Root.Base (Object),
> >             Object2    => Object2) ;
> >     end Some_Proc ;
> > end Root.Child1 ;
> >
> > package Root.Child1.Child2 is
> >     type Derive2 is new Derive1 with private ;
> >     procedure Some_Proc (
> >         Object         : in out Derive2;
> >         Object2        : in out Derive2'Class) ;
> > private
> >     type Derive2 is new Derive1 with record
> >         Data_Item_3    : Natural    := 0 ;
> >     end record ;
> > end Root.Child1.Child2 ;
> >
> > package body Root.Child1.Child2 is
> >     procedure Some_Proc (
> >         Object         : in out Derive2;
> >         Object2        : in out Derive2'Class) is
> >     begin
> >         --
> >         --    Dies here with the following error message:
> >         --
> >         --    root-child1-child2.adb:15:20: ambiguous expression (cannot
> > resolve "Some_Proc")
> >         --    root-child1-child2.adb:15:20: possible interpretation at
> > root-child1.ads:4
> >         --    root-child1-child2.adb:15:20: possible interpretation at
> > root-child1.ads:3
> >         --    gnatmake: "root-child1-child2.adb" compilation error
> >         --
> >         Root.Child1.Some_Proc (
> >             Object     => Root.Child1.Derive1 (Object),
> >             Object2    => Object2) ;
> >     end Some_Proc ;
> > end Root.Child1.Child2 ;
> >
> > Thanks for any help you can offer.
> >
> > 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
> http://members.home.net/ve3wwg

-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: Ambiguous reference - What is wrong with this?

[Marin David Condic]

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

Re: Ambiguous reference - What is wrong with this?

[Warren W. Gay VE3WWG]

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

Re: Ambiguous reference - What is wrong with this?

[Sergey Koshcheyev]

Hi!

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:9lbf8n$brf$1@nh.pace.co.uk...
> O.K. I've got a compilation problem that is most likely due to my
> misunderstanding of some language rule. Below is some code that shows a
> simplified version of the problem. I'm using Gnat 3.13p on a WinNT PC.
>
> I'm pretty sure that the problem has something to do with the 'Class
> parameters creating some kind of ambiguity - but given that I've fully
> qualified the names, it seems like the compiler ought to know which
> procedure I meant to call. The quest6ion is twofold: Am I doing something
> illegal (if so, what?) and if it *is* illegal, then is there an alternate
> way of doing essentially the same thing? (One parameter being of a
specific
> descendent and the other being a class-wide parameter. The class wide
> parameter wants to be an increasingly restrictive subset as you move down
> the chain of child packages)

It looks to me that the problem is this: when you derive a type from some
other type, the derived type gets the primitive operations of the parent.
However, the dispatching parameter type (I'm not sure if it's the correct
terminology) gets changed from the base type to the derived type. The
parameter of type 'Class, on the other hand, remains untouched.
What this leads to is this: when you declare Some_Proc for the Derive1 type,
it does not override the Some_Proc of Base, but *overloads* it. This means
that the type Derive1 has *two* primitive operations, and the type Derive2
has three. They are:

procedure Some_Proc
  (Object : in out Derive2;
   Object2 : in out Base'Class);
procedure Some_Proc
  (Object : in out Derive2;
   Object2 : in out Derive1'Class);
procedure Some_Proc
  (Object : in out Derive2;
   Object2 : in out Derive2'Class);

and these are the three operations that the compiler can't choose from. A
way to overcome this problem would be to rename the Some_Proc you actually
call to some other name. Qualifying the parameters, like
         Root.Child1.Some_Proc (
             Object     => Root.Child1.Derive1 (Object),
             Object2    => Root.Child1.Derive1'Class'(Object2)) ;
(note the qualification of Object2) doesn't work.

Sergey Koshcheyev

Re: Ambiguous reference - What is wrong with this?

[Marin David Condic]

Hmmmmmm........ I *think* I understand. This may take a bit of pondering.

In any event, it isn't clear how I get out of it considering thatI'd kind of
like to keep the second parameter a 'Class wide type.

I'll have to cogitate on this - but it appears I may not be able to get
there from here. If I'm creating overloadings and qualifying the
overloadings isn't disambiguating them, then it seems the only answer is to
create new names. However doing so means the child class a couple of layers
down can't hide some operation of one of its parents. I'd like to be able to
say my list can only accept elements of some subclass and increasingly
restrict that subclass (see other posts in this thread.) By removing the
'Class qualification, I may avoid the ambiguity, but may not be able to
preserve the subsets I want to have.

Hmmmmmmm............

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/


"Sergey Koshcheyev" <serko84@hotmail.com> wrote in message
news:9lbo1h$2bhq$1@ns.felk.cvut.cz...
>
> It looks to me that the problem is this: when you derive a type from some
> other type, the derived type gets the primitive operations of the parent.
> However, the dispatching parameter type (I'm not sure if it's the correct
> terminology) gets changed from the base type to the derived type. The
> parameter of type 'Class, on the other hand, remains untouched.
> What this leads to is this: when you declare Some_Proc for the Derive1
type,
> it does not override the Some_Proc of Base, but *overloads* it. This means
> that the type Derive1 has *two* primitive operations, and the type Derive2
> has three. They are:
>
> procedure Some_Proc
>   (Object : in out Derive2;
>    Object2 : in out Base'Class);
> procedure Some_Proc
>   (Object : in out Derive2;
>    Object2 : in out Derive1'Class);
> procedure Some_Proc
>   (Object : in out Derive2;
>    Object2 : in out Derive2'Class);
>
> and these are the three operations that the compiler can't choose from. A
> way to overcome this problem would be to rename the Some_Proc you actually
> call to some other name. Qualifying the parameters, like
>          Root.Child1.Some_Proc (
>              Object     => Root.Child1.Derive1 (Object),
>              Object2    => Root.Child1.Derive1'Class'(Object2)) ;
> (note the qualification of Object2) doesn't work.
>

Re: Ambiguous reference - What is wrong with this?

[Sergey Koshcheyev]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:9lc0jf$hod$1@nh.pace.co.uk...
> Hmmmmmm........ I *think* I understand. This may take a bit of pondering.

Well, I should have explained that better, let me try it once more :-)
The problem is that you're overloading instead of overriding. And the
problem occurs because when Some_Proc is inherited for type Derive1, it
turns from
procedure Some_Proc
  (Object  : in out Base;
   Object2 : in out Base'Class);
to
procedure Some_Proc
  (Object  : in out Derive1;
   Object2 : in out Base'Class);
(note that the type of the Object2 parameter doesn't change)
so the Some_Proc you define doesn't override it.

> In any event, it isn't clear how I get out of it considering thatI'd kind
of
> like to keep the second parameter a 'Class wide type.

Ada is not covariant, so I'm quite sure an approach using tagged types for
both the containers and the  elements (in the context of your problem) won't
work.

> <snip>
> down can't hide some operation of one of its parents. I'd like to be able
to
> say my list can only accept elements of some subclass and increasingly
> restrict that subclass (see other posts in this thread.) By removing the

I think that having the root list package generic and adding new generic
parameters to child packages (and thus adding requirements for the stored
type) might work, but I haven't tested it and I don't know if it will be
appropriate for the problem you're solving. I can provide an example of what
I have in mind, if needed.

Sergey.

Re: Ambiguous reference - What is wrong with this?

[Marin David Condic]

O.K. I think I've got it. At the first level of derivation, I've rather
implicitly created a Derive1/Base'Class procedure which looks essentially
the same as a Derive1/Derive1'Class procedure because, after all, a
Derive1'Class is also a Base'Class. The attempt to resolve it doesn't work
because there are, in effect, two procedures in the package spec - one that
I visibly created and one that is automagically created. So basically, I can
get away with this if I only go to one level of derivation, but the next
level up is going to see duplicate procedures below it.

Well, I'll need to ponder this for a while & see what alternative approaches
I might take. Generics suggest one possible answer, but I don't find it as
clean as an abstract tagged type for bringing in lots of user defined
functions. Whatever happens, I think I'm in a position where I have to do
some major restructuring of what I've got so far. Bummer, dude! :-(

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/


"Sergey Koshcheyev" <serko84@hotmail.com> wrote in message
news:9ld8su$eak$1@ns.felk.cvut.cz...
>
> "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
> message news:9lc0jf$hod$1@nh.pace.co.uk...
> > Hmmmmmm........ I *think* I understand. This may take a bit of
pondering.
>
> Well, I should have explained that better, let me try it once more :-)
> The problem is that you're overloading instead of overriding. And the
> problem occurs because when Some_Proc is inherited for type Derive1, it
> turns from
> procedure Some_Proc
>   (Object  : in out Base;
>    Object2 : in out Base'Class);
> to
> procedure Some_Proc
>   (Object  : in out Derive1;
>    Object2 : in out Base'Class);
> (note that the type of the Object2 parameter doesn't change)
> so the Some_Proc you define doesn't override it.
>
> > In any event, it isn't clear how I get out of it considering thatI'd
kind
> of
> > like to keep the second parameter a 'Class wide type.
>
> Ada is not covariant, so I'm quite sure an approach using tagged types for
> both the containers and the  elements (in the context of your problem)
won't
> work.
>
> > <snip>
> > down can't hide some operation of one of its parents. I'd like to be
able
> to
> > say my list can only accept elements of some subclass and increasingly
> > restrict that subclass (see other posts in this thread.) By removing the
>
> I think that having the root list package generic and adding new generic
> parameters to child packages (and thus adding requirements for the stored
> type) might work, but I haven't tested it and I don't know if it will be
> appropriate for the problem you're solving. I can provide an example of
what
> I have in mind, if needed.
>
> Sergey.
>
>

Re: Ambiguous reference - What is wrong with this?

[tmoran]

I think the problem occurs back at
package Root.Child1 is
    type Derive1 is new Base with private ;
inherits
    procedure Some_Proc (
        Object         : in out Derive1;  -- was Base
        Object2        : in out Base'Class) ;
and then you declare another procedure, with a different second parameter,
    procedure Some_Proc (
        Object         : in out Derive1;
        Object2        : in out Derive1'Class) ;
now which is
        Root.Child1.Some_Proc (
            Object     => Root.Child1.Derive1 (Object),
            Object2    => Object2) ;  -- in Derive1'Class and Base'Class
supposed to be calling?

Re: Ambiguous reference - What is wrong with this?

[Simon Wright]

tmoran@acm.org writes:

> I think the problem occurs back at
> package Root.Child1 is
>     type Derive1 is new Base with private ;
> inherits
>     procedure Some_Proc (
>         Object         : in out Derive1;  -- was Base
>         Object2        : in out Base'Class) ;
> and then you declare another procedure, with a different second parameter,
>     procedure Some_Proc (
>         Object         : in out Derive1;
>         Object2        : in out Derive1'Class) ;
> now which is
>         Root.Child1.Some_Proc (
>             Object     => Root.Child1.Derive1 (Object),
>             Object2    => Object2) ;  -- in Derive1'Class and Base'Class
> supposed to be calling?

        Root.Child1.Some_Proc (
            Object     => Root.Child1.Derive1 (Object),
            Object2    => Root.Base'Class (Object2)) ;

compiles OK (GNAT 3.14a)

Re: Ambiguous reference - What is wrong with this?

[Marin David Condic]

I just tried this with Gnat 3.13p and it seemed to work The question in my
mind is will it do the thing I want it to do? I convert Object2 back to the
base type & presumably everything is fine if the lower level Some_Proc wants
to dynamically allocate something that matches. But have I prevented
something from entering that isn't of the more specific Derive1 type? If
converting back to the Base type finds a matching procedure, couldn't
something that is not of Derive1 type enter the Some_Proc?

In other words, if I'm using this to restrict some child type list from
having data values put into it that don't match some more complex derived
child class, am I not just circumventing that check?

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/


"Simon Wright" <simon@pushface.org> wrote in message
news:x7v1ymdyhi0.fsf@smaug.pushface.org...
> tmoran@acm.org writes:
>
>         Root.Child1.Some_Proc (
>             Object     => Root.Child1.Derive1 (Object),
>             Object2    => Root.Base'Class (Object2)) ;
>
> compiles OK (GNAT 3.14a)