Re: Generic procedures and their parameters

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 06 Sep 2006 09:02:51 -0400, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Wed, 06 Sep 2006 10:51:48 +0200, Maciej Sobczak wrote:
>> 
>>> eneric
>>>     type Index_Type   is (<>);
>>>     type Element_Type is private;
>>>     type Array_Type   is array (Index_Type range <>) of Element_Type;
>>>     with function "<" (Left, Right : in Element_Type) return Boolean is <>;
>>> procedure Sort(To_Sort : in out Array_Type);
>>> 
>>> My question is: what's the purpose of the third parameter (Array_Type)? 
>>> Isn't it implied by the first two and therefore just redundant?
>> 
>> Reverse. Actually Index_Type and Element_Type are redundant. In a better
>> Ada it should be:
>> 
>>    generic
>>       type Container_Type is array (<>) of <>;
>>              -- or "(<>) is limited private array"
>>       with function "<" (Left, Right : in Container_Type'Element)
>>          return Boolean is <>;
>>    procedure Sort (To_Sort : in out Container_Type);
>> 
>> [ Even better it be non-generic:
>> 
>>    procedure Sort (To_Sort : in out Container_Of_Ordered'Class);
>> 
>> where each container type (like an array) be a member of the class, if its
>> elements are in Ordered'Class. ]
> 
> I think you mean Sequence_Of_Ordered -- not all containers can be
> sorted.

Right, both the index type and the element types have to be ordered, and
also the element type should be non-limited.

> But I agree that it would be nice to have such a feature.  It works for
> the built-in array types -- you magically get "and" if the component is
> Boolean, "<" if the component is discrete, ":=" if the component is
> non-limited.  I don't know of a good way to do that sort of thing for
> user-defined containers.

The user-defined container should implement the corresponding interface. As
you said, the interface could have two type discriminants (physically type
tags):

Index : type Abstract_Ordered;
Element : type Abstract_Ordered

Because interfaces are MI, an array of Boolean could implement Lattice
interface, which would give the user and, or, not etc. Upon declaration he
would specify the interfaces his container promises to implement.

The problems with that, as I can see:

1. inheritance/overriding/merging of discriminants (diamond diagram).
Clearly Index and Element in all interfaces should be same.

2. an intelligent and effective elimination of statically-known
discriminants at run-time.

BTW, if that worked, we could remove built-in tagged types replacing them
by an interface with the Tag discriminant.

There is another interesting thing to investigate. If a type has many
type-discriminants, then for each such discriminant (including its own
tag), it should have a class. I.e. by analogy with T'First(n) attributes
there will be Container'Class, Contrainer'Class(Index),
Container'Class(Element). That would open a range of possibilities. For
example one could derive from Container along the 'Element' axis. The
result should be a class of containers with elements from Element'Class.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de