Delegating operations to parent (generic formal type)

Delegating operations to parent (generic formal type)

[Simon Wright]

The code below is accepted by GNAT (3.13a1, 3.12p at least) but not by
APEX 3.2.0b (Solaris) or the OA demo edition.

The problem arises in the body of Containers.Maps.Synchronized.

APEX says it can't resolve the call Initialize (Map_Base (M)) in
Containers.Maps.Synchronized.Initialize.

OA says the call to Bind (Map_Base (M)) is a non-dispatching call on
an abstract subprogram. I think it may be confused, it mutters also
about "internal error".

This is a pretty common idiom in Smalltalk (super bind, super
initialize) -- is there an Ada equivalent that would help here? I can
believe that OA is wrong, it's very old now, but I can't see why APEX
doesn't see the Initialize(Map_Base) operation.

=============================================================================
with Ada.Finalization;
package Containers is
  type Container is abstract tagged private;
private
  type Container is abstract new Ada.Finalization.Controlled with null record;
end Containers;

package Containers.Maps is
  type Map is abstract new Container with private;
  procedure Bind (M : in out Map) is abstract;
private
  type Map is abstract new Container with null record;
end Containers.Maps;

package Containers.Maps.Unbounded is
  type Unbounded_Map is new Map with private;
  procedure Bind (M : in out Unbounded_Map);
private
  type Unbounded_Map is new Map with null record;
  procedure Initialize (M : in out Unbounded_Map);
end Containers.Maps.Unbounded;

package body Containers.Maps.Unbounded is
  procedure Bind (M : in out Unbounded_Map) is
  begin
    null;
  end Bind;
  procedure Initialize (M : in out Unbounded_Map) is
  begin
    null;
  end Initialize;
end Containers.Maps.Unbounded;

generic
  type Map_Base is new Containers.Maps.Map with private;
package Containers.Maps.Synchronized is
  type Synchronized_Map is new Map_Base with private;
  procedure Bind (M : in out Synchronized_Map);
private
  type Synchronized_Map is new Map_Base with null record;
  procedure Initialize (M : in out Synchronized_Map);
end Containers.Maps.Synchronized;

package body Containers.Maps.Synchronized is
  procedure Bind (M : in out Synchronized_Map) is
  begin
    Bind (Map_Base (M));                         -- this is OK in APEX
  end Bind;
  procedure Initialize (M : in out Synchronized_Map) is
  begin
    Initialize (Map_Base (M));                   -- this is complained about
  end Initialize;
end Containers.Maps.Synchronized;

with Containers.Maps.Synchronized;
with Containers.Maps.Unbounded;
package User is
  package Synchronized_Unbounded_Map
  is new Containers.Maps.Synchronized
     (Map_Base => Containers.Maps.Unbounded.Unbounded_Map);
end User;

Re: Delegating operations to parent (generic formal type)

[tmoran]

If you delete procedure Initialize from package Containers.Maps.Unbounded,
then what procedure is supposed to be called by
    Initialize (Map_Base (M));                   -- this is complained about
in package Containers.Maps.Synchronized?

Re: Delegating operations to parent (generic formal type)

[Simon Wright]

tmoran@bix.com writes:

> If you delete procedure Initialize from package Containers.Maps.Unbounded,
> then what procedure is supposed to be called by
>     Initialize (Map_Base (M));                   -- this is complained about
> in package Containers.Maps.Synchronized?

What I would _hope_ is that the default (null) one in Ada.Finalization
would get called. Or, if Containers had one, then that one.

I did try Initialize (Map_Base'Class (M)) but that ends up being a
recursive call to Containers.Maps.Synchronized.Initialize .

Re: Delegating operations to parent (generic formal type)

[Simon Wright]

Christoph Grein <christoph.grein@eurocopter.de> can't post directly,
but says:

  It's really funny, I've just published an article about this
  behaviour in the Ada Germany's periodical. You can find the English
  version on my homepage and also in AdaPower in the Language section.

  http://home.T-Online.de/home/Christ-Usch.Grein/AdaMagica/Secretive.html

  You'll find the problem solution there.

Re: Delegating operations to parent (generic formal type)

[Simon Wright]

Simon Wright <simon@pogner.demon.co.uk> writes:

> Christoph Grein <christoph.grein@eurocopter.de> can't post directly,
> but says:
> 
>   It's really funny, I've just published an article about this
>   behaviour in the Ada Germany's periodical. You can find the English
>   version on my homepage and also in AdaPower in the Language section.
> 
>   http://home.T-Online.de/home/Christ-Usch.Grein/AdaMagica/Secretive.html
> 
>   You'll find the problem solution there.

Christoph,

Your article is about the fact that primitive operations can only
override visible operations of a parent type.

Although I take your point, in my case the operations were in a child
package -- exactly like yours! -- so the inheritance from
Ada.Finalization.Controlled should have been visible.

Interestingly, when I made the inheritance public, Apex crashed in the
"middle pass" (AFAICR).

Re: Delegating operations to parent (generic formal type)

[Simon Wright]

(This is a repost, in the hope someone can help!!)

The code below is accepted by GNAT (3.13a1, 3.12p at least) but not by
APEX 3.2.0b (Solaris) or the OA special edition (7.2).

The problem arises in the body of Containers.Maps.Synchronized.

APEX says it can't resolve the call Initialize (Map_Base (M)) in
Containers.Maps.Synchronized.Initialize.

OA ditto, followed by a fatal assertion error (or was it a bad memory
access?) in the instantiation.

This is a pretty common idiom in Smalltalk (super bind, super
initialize) -- is there an Ada equivalent that would help here? I
can't see why the compilers don't see the Initialize(Map_Base)
operation, we're in a child package and should be able to see the
private operations of Map_Base -- which include those of Controlled.

=============================================================================
with Ada.Finalization;
package Containers is
  type Container is abstract tagged private;
private
  type Container is abstract new Ada.Finalization.Controlled with null record;
end Containers;

package Containers.Maps is
  type Map is abstract new Container with private;
  procedure Bind (M : in out Map) is abstract;
private
  type Map is abstract new Container with null record;
end Containers.Maps;

package Containers.Maps.Unbounded is
  type Unbounded_Map is new Map with private;
  procedure Bind (M : in out Unbounded_Map);
private
  type Unbounded_Map is new Map with null record;
  procedure Initialize (M : in out Unbounded_Map);
end Containers.Maps.Unbounded;

package body Containers.Maps.Unbounded is
  procedure Bind (M : in out Unbounded_Map) is
  begin
    null;
  end Bind;
  procedure Initialize (M : in out Unbounded_Map) is
  begin
    null;
  end Initialize;
end Containers.Maps.Unbounded;

generic
  type Map_Base is new Containers.Maps.Map with private;
package Containers.Maps.Synchronized is
  type Synchronized_Map is new Map_Base with private;
  procedure Bind (M : in out Synchronized_Map);
private
  type Synchronized_Map is new Map_Base with null record;
  procedure Initialize (M : in out Synchronized_Map);
end Containers.Maps.Synchronized;

package body Containers.Maps.Synchronized is
  procedure Bind (M : in out Synchronized_Map) is
  begin
    Bind (Map_Base (M));                         -- this is OK in APEX
  end Bind;
  procedure Initialize (M : in out Synchronized_Map) is
  begin
    Initialize (Map_Base (M));                   -- this is complained about
  end Initialize;
end Containers.Maps.Synchronized;

with Containers.Maps.Synchronized;
with Containers.Maps.Unbounded;
package User is
  package Synchronized_Unbounded_Map
  is new Containers.Maps.Synchronized
     (Map_Base => Containers.Maps.Unbounded.Unbounded_Map);
end User;

Re: Delegating operations to parent (generic formal type)

[Tucker Taft]

Simon Wright wrote:
> 
> (This is a repost, in the hope someone can help!!)
> 
> The code below is accepted by GNAT (3.13a1, 3.12p at least) but not by
> APEX 3.2.0b (Solaris) or the OA special edition (7.2).
> 
> The problem arises in the body of Containers.Maps.Synchronized.
> 
> APEX says it can't resolve the call Initialize (Map_Base (M)) in
> Containers.Maps.Synchronized.Initialize.
> 
> OA ditto, followed by a fatal assertion error (or was it a bad memory
> access?) in the instantiation.
> 
> This is a pretty common idiom in Smalltalk (super bind, super
> initialize) -- is there an Ada equivalent that would help here? I
> can't see why the compilers don't see the Initialize(Map_Base)
> operation, we're in a child package and should be able to see the
> private operations of Map_Base -- which include those of Controlled.

The use of Initialize is legal.  This looks like an old-fashioned
bug in APEX and ObjectAda 7.2.  The current AdaMagic front end has no
problem "seeing" the Initialize operation.

-Tuck
-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Commercial Division, AverStar (formerly Intermetrics)
(http://www.averstar.com/services/IT_consulting.html)  Burlington, MA  USA

Re: Delegating operations to parent (generic formal type)

[Simon Wright]

Tucker Taft <stt@averstar.com> writes:

> The use of Initialize is legal.  This looks like an old-fashioned
> bug in APEX and ObjectAda 7.2.  The current AdaMagic front end has no
> problem "seeing" the Initialize operation.

Tucker,

Thanks very much. I'll pass on PRs ..

The following is a repost of my article "Visibility for operations of
formal private extensions" <x7v4s5af41m.fsf@pogner.demon.co.uk> which
seems to have similar difficulty. I'd be most grateful for any
comments ..

The code below gives compilation errors when compiling the view
conversion in P.Q.R.Proc's body, both in GNAT (3.13a1) and Apex
3.2.0b. They say that there's no visible interpretation: GNAT says

/home/simon/tmp/demo.ada:33:09: no candidate interpretations match the actuals:
/home/simon/tmp/demo.ada:33:15: expected type "New_T" defined at /home/simon/tmp/demo.ada:26
/home/simon/tmp/demo.ada:33:15: found private type "Base" defined at /home/simon/tmp/demo.ada:22
/home/simon/tmp/demo.ada:33:15:   ==> in call to "Proc" at /home/simon/tmp/demo.ada:27
/home/simon/tmp/demo.ada:33:15:   ==> in call to "Proc" at /home/simon/tmp/demo.ada:18(inherited)
/home/simon/tmp/demo.ada:33:15:   ==> in call to "Proc" at /home/simon/tmp/demo.ada:5

If I make P.Proc publicly visible, the compilation goes fine.

I believe we are somewhere near 12.5.1(21) here. My belief that it
should have compiled is based on the following:

* we know that P.Q.R.Base is a P.Q.Q_T

* a P.Q.Q_T (privately) inherits P.Proc

* P.Q.R's body has visiblity of the private part of P and therefore
  should be able to see that P.Q.Q_T inherits P.Proc

Note that P.Q.S's body _can_ see P.Proc.

I tried adding a private component to P.Q.Q_T, P.Q.R.Proc can see it
quite happily .. OK, the LRM reference above is about operations not
data, still!

==================================================================
package P is
    type T is tagged private;
private
    type T is tagged null record;
    procedure Proc (The_T : in out T);
end P;

package body P is
    procedure Proc (The_T : in out T) is
    begin
        null;
    end Proc;
end P;

package P.Q is
    type Q_T is new P.T with private;
private
    type Q_T is new T with null record;
end P.Q;

generic
    type Base is new Q_T with private;
package P.Q.R is
    type New_T is new Base with private;
private
    type New_T is new Base with null record;
    procedure Proc (The_T : in out New_T);
end P.Q.R;

package body P.Q.R is
    procedure Proc (The_T : in out New_T) is
    begin
        Proc (Base (The_T));
    end Proc;
end P.Q.R;

package P.Q.S is
    type S_T is new Q_T with private;
private
    type S_T is new Q_T with null record;
    procedure Proc (The_T : in out S_T);
end P.Q.S;

package body P.Q.S is
    procedure Proc (The_T : in out S_T) is
    begin
        Proc (Q_T (The_T));
    end Proc;
end P.Q.S;

with P.Q.R;
with P.Q.S;
package U is
    package U_P is new P.Q.R (Base => P.Q.S.S_T);
end U;

Re: Delegating operations to parent (generic formal type)

[Tucker Taft]

Simon Wright wrote:
> 
> Tucker Taft <stt@averstar.com> writes:
> 
> > The use of Initialize is legal.  This looks like an old-fashioned
> > bug in APEX and ObjectAda 7.2.  The current AdaMagic front end has no
> > problem "seeing" the Initialize operation.
> 
> Tucker,
> 
> Thanks very much. I'll pass on PRs ..
> 
> The following is a repost of my article "Visibility for operations of
> formal private extensions" <x7v4s5af41m.fsf@pogner.demon.co.uk> which
> seems to have similar difficulty. I'd be most grateful for any
> comments ..

This also looks like the same bug.  The body of a generic should
be able to see the private operations in its parent unit.

> ...

-Tuck
-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Commercial Division, AverStar (formerly Intermetrics)
(http://www.averstar.com/services/IT_consulting.html)  Burlington, MA  USA