Generic abstracts

Generic abstracts

[Lutz Donnerhacke]

Somebody might remember a unspecific quotation from the reference manual
about prohibiting abstract declarations in generic packages.

In my current developemnt I came across this problem again.

generic
   type S (<>) is abstract tagged limited private;
package X is
   type T        is abstract new S with private;
   type T_Class  is access all T'Class;
   type Bla      is limited private;
   type Position is private;

   procedure Set (B : in out Bla;
                  E : in     T_Class);
		  
   function  Get (B : in     Bla) return T_Class;

   generic
      with procedure On_Item (E : in out S);
   procedure         Iterate (B : in     Bla);

   generic
      with function Is_Match (E : in S)   return Boolean;
   function         Find     (B : in Bla) return Position;
end X;

I will guarantee this interface (Set/Get) over several implementations.
The na�ve approach fails:

generic
   type S (<>) is abstract tagged limited private;
package X is
   type T       is abstract new S null record;
   type T_Class is access all T'Class;
   type Bla     is abstract tagged limited null record;

   procedure Set (B : in out Bla;
                  E : in     T_Class)            is abstract;
		  
   function  Get (B : in     Bla) return T_Class is abstract;
   
   generic
      with procedure On_Item (E : in out S);
   procedure         Iterate (B : in     Bla)    is abstract;
--                                               ^ missing ';'.
-- Providing a sensless dummy function works.

   generic
      with function Is_Match (E : in S)   return Boolean;
   function         Find     (B : in Bla) return Position is abstract;
--                                                        ^ missing ';'.
-- Providing a dummy function is not possible, because no return value exists.
end X;

The abstract definition should be used to ensure a consistent
inteface. I have two problems:
  - A generic procedure which can be missed on implementation.
    Raising an exception might be acceptable.
  - It is not possible to predefine a body for a generic function.
    No return value is available.
    Raising an exception does not stop the compiler from requiring
    a return value.    

Any hints?    

Re: Generic abstracts

[Lutz Donnerhacke]

[I'm doing the Ingrid.�]

* Lutz Donnerhacke wrote:
>In my current developemnt I came across this problem again.

ftp://ftp.iks-jena.de/pub/mitarb/lutz/ada/types/

Classic data structures like List, Hash, ... are usually implemented as a
generic package over an item type. They result in a new component type
containing the items.

This packages embell the items to be managed by a component type.
So it allowes an item to be a member of multiple structures at the same time
without expecting anything special from it.

It should be possible to create a hash and two lists over a set of
unconstraint abstract types containing task components.

YFYI.
\f
1 "Doing the Ingrid" is a common phrase in de.ALL, the international
  German speaking usenet groups. It refers to a penetrant girl polluting
  some groups by a series of recursive followups.

Re: Generic abstracts

[Tucker Taft]

Lutz Donnerhacke wrote:
> 
> Somebody might remember a unspecific quotation from the reference manual
> about prohibiting abstract declarations in generic packages.
> 
> In my current developemnt I came across this problem again.
> ...
>    generic
>       with procedure On_Item (E : in out S);
>    procedure         Iterate (B : in     Bla)    is abstract;
> --                                               ^ missing ';'.
> -- Providing a sensless dummy function works.
> 
>    generic
>       with function Is_Match (E : in S)   return Boolean;
>    function         Find     (B : in Bla) return Position is abstract;
> --                                                        ^ missing ';'.
> -- Providing a dummy function is not possible, because no return value exists.
> end X;
> 
> The abstract definition should be used to ensure a consistent
> inteface. I have two problems:
>   - A generic procedure which can be missed on implementation.
>     Raising an exception might be acceptable.
>   - It is not possible to predefine a body for a generic function.
>     No return value is available.
>     Raising an exception does not stop the compiler from requiring
>     a return value.
> 
> Any hints?

I'm unclear as to what you are trying to accomplish by including
generic subprograms that are abstract.  Generic subprograms are
not inherited, so there is no point in declaring them on an
abstract type.  

Perhaps if you showed how the generic package was going to be
instantiated and used, I might be able to suggest a solution to
your problem.


-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Generic abstracts

[Lutz Donnerhacke]

* Tucker Taft wrote:
>Lutz Donnerhacke wrote:
>> The abstract definition should be used to ensure a consistent
>> interface. I have two problems:
>>   - A generic procedure which can be missed on implementation.
>>     Raising an exception might be acceptable.
>>   - It is not possible to predefine a body for a generic function.
>>     No return value is available.
>>     Raising an exception does not stop the compiler from requiring
>>     a return value.
>
>I'm unclear as to what you are trying to accomplish by including
>generic subprograms that are abstract.  Generic subprograms are
>not inherited, so there is no point in declaring them on an
>abstract type.  

with Abstract_Lists;

generic
   type Item (<>) is abstract tagged limited private;
package Concrete_Lists is
   package Abstract_Template is
      new Abstract_Lists (Item => Item);

   type List          is new Abstract_Template.List          with private;
   type List_Item     is new Abstract_Template.List_Item     with private;
   type List_Iterator is new Abstract_Template.List_Iterator with private;

   -- now the compiler requires to implement all abstract functions
   -- including the generic Iterate and Delete procedures

   function Is_Empty (L : List) return Boolean;

   generic
      with procedure On_Item (E : in out Item);
   procedure For_Each        (L : in     List);

   ...
end Concrete_Lists;

An solution without (abtract) interfaces can be obtained from
ftp.iks-jena.de:/pub/mitarb/lutz/ada/types/

Re: Generic abstracts

[Tucker Taft]

Lutz Donnerhacke wrote:
> 
> * Tucker Taft wrote:
> >Lutz Donnerhacke wrote:
> >> The abstract definition should be used to ensure a consistent
> >> interface. I have two problems:
> >>   - A generic procedure which can be missed on implementation.
> >>     Raising an exception might be acceptable.
> >>   - It is not possible to predefine a body for a generic function.
> >>     No return value is available.
> >>     Raising an exception does not stop the compiler from requiring
> >>     a return value.
> >
> >I'm unclear as to what you are trying to accomplish by including
> >generic subprograms that are abstract.  Generic subprograms are
> >not inherited, so there is no point in declaring them on an
> >abstract type.
> 
> with Abstract_Lists;
> 
> generic
>    type Item (<>) is abstract tagged limited private;
> package Concrete_Lists is
>    package Abstract_Template is
>       new Abstract_Lists (Item => Item);
> 
>    type List          is new Abstract_Template.List          with private;
>    type List_Item     is new Abstract_Template.List_Item     with private;
>    type List_Iterator is new Abstract_Template.List_Iterator with private;
> 
>    -- now the compiler requires to implement all abstract functions
>    -- including the generic Iterate and Delete procedures

So you would like a derived type to inherit the generic
subprogrmas of its parent type, and if they are abstract,
be required to implement them?  This seems like a reasonable
request, but Ada has never supported inheritance of anything
but subprograms and enumerals.  One could imagine inheriting other 
things I suppose, such as exceptions, generics, subpackages, etc. 
However, at the moment only "overloadable" things (i.e. subprograms 
and enumerals) are inheritable, and that has some nice properties.

Be that as it may, I now understand what you were trying to do
and can safely answer that it is not supported by the Ada inheritance
model.

> 
>    function Is_Empty (L : List) return Boolean;
> 
>    generic
>       with procedure On_Item (E : in out Item);
>    procedure For_Each        (L : in     List);
> 
>    ...
> end Concrete_Lists;
> 
> An solution without (abtract) interfaces can be obtained from
> ftp.iks-jena.de:/pub/mitarb/lutz/ada/types/

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Generic abstracts

[Robert A Duff]

Tucker Taft <stt@averstar.com> writes:

> However, at the moment only "overloadable" things (i.e. subprograms 
> and enumerals) are inheritable, and that has some nice properties.

I don't see the connection between overloadable and inheritable.

By the way, I have wanted to write overloaded generic functions in the
past...

- Bob

Re: Generic abstracts

[Lutz Donnerhacke]

* Tucker Taft wrote:
>So you would like a derived type to inherit the generic
>subprogrmas of its parent type, and if they are abstract,
>be required to implement them?

Yep.

>Be that as it may, I now understand what you were trying to do
>and can safely answer that it is not supported by the Ada inheritance
>model.

Thnx. I'll spend efforts on other topics now.

Re: Generic abstracts

[Tucker Taft]

Robert A Duff wrote:
> 
> Tucker Taft <stt@averstar.com> writes:
> 
> > However, at the moment only "overloadable" things (i.e. subprograms
> > and enumerals) are inheritable, and that has some nice properties.
> 
> I don't see the connection between overloadable and inheritable.

By restricting inheritance to overloadable things, you don't get
collisions when you have two derived types in the same scope, since
overloadables won't hide each other unless they have identical
types, which can't happen when defining a new derived type.

> 
> By the way, I have wanted to write overloaded generic functions in the
> past...

I can't help you with that today ;-).
> 
> - Bob

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA