Generic procedures and their parameters

Generic procedures and their parameters

[Maciej Sobczak]

Hi,

I have found the following signature for the sorting procedure:

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?


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Generic procedures and their parameters

[Dmitry A. Kazakov]

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

Regarding Array_Type being implied, it is not. You can have any number of
array types based on exactly same combination of index and element types.
These types will be different types:

type I is ...;
type E is ...;
type Array1 is array (I range <>) of E;
type Array2 is array (I range <>) of E;

The types Array1 and Array2 are distinct types. Sort must be instantiated
for each of them (or else you have to convert types).

The reverse is a different story. It is a pity that Ada does not have
attributes to get the index and element types from the array type
(container type). The next step would be getting "<" from the element type,
which would eliminate a need to have Sort generic.

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

Re: Generic procedures and their parameters

[Maciej Sobczak]

Dmitry A. Kazakov 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);

OK, it makes perfect sense.

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

But then, you would need to have even such fundamental things like 
Integer belong to Ordered'Class. It's a shaky ground.

> Regarding Array_Type being implied, it is not. You can have any number of
> array types based on exactly same combination of index and element types.
> These types will be different types:
> 
> type I is ...;
> type E is ...;
> type Array1 is array (I range <>) of E;
> type Array2 is array (I range <>) of E;

> The types Array1 and Array2 are distinct types.

And now I see. I'm still having troubles with the fact that 
"granularity" of type system in Ada can be much smaller than what can be 
achieved with structural differences only.

> The reverse is a different story. It is a pity that Ada does not have
> attributes to get the index and element types from the array type
> (container type).

Yes.

> The next step would be getting "<" from the element type,
> which would eliminate a need to have Sort generic.

No, I disagree. There is a place for generic subprograms, otherwise we'd 
have everything in a single hierarchy with Object at the top. It's not a 
coincidence that "other languages" drift towards supporting generics, 
even if they already had such single-rooted hierarchies.


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Generic procedures and their parameters

[Robert A Duff]

Maciej Sobczak <no.spam@no.spam.com> writes:

> Hi,
> 
> I have found the following signature for the sorting procedure:
> 
> 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?

Well, if you simply erase the Array_Type formal, then the reference to
Array_Type in the declaration of To_Sort would be in error.
And you cannot say this:

generic
    type Index_Type   is (<>);
    type Element_Type is private;
    with function "<" (Left, Right : in Element_Type) return Boolean is <>;
procedure Sort(To_Sort : in out array (Index_Type range <>) of Element_Type); -- Illegal syntax!

because Ada uses "by name" type equivalence (mostly).  In this case,
structural equivalence might be more convenient.

You could do it this way:

generic
    type Index_Type   is (<>);
    type Element_Type is private;
    with function "<" (Left, Right : in Element_Type) return Boolean is <>;
package Sorting is

    type Array_Type   is array (Index_Type range <>) of Element_Type;
    procedure Sort(To_Sort : in out Array_Type);

end Sorting;

but that's less flexible for the client, because it can't use it's own
array type.

- Bob

Re: Generic procedures and their parameters

[Robert A Duff]

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

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.  If generics could do that, then "array" could
just be a generic, rather than having built-in syntax and semantics.
Eiffel does it that way.

- Bob

Re: Generic procedures and their parameters

[Robert A Duff]

Maciej Sobczak <no.spam@no.spam.com> writes:

> But then, you would need to have even such fundamental things like
> Integer belong to Ordered'Class. It's a shaky ground.

Why is that shaky?  Integer IS ordered.

> > Regarding Array_Type being implied, it is not. You can have any number of
> > array types based on exactly same combination of index and element types.
> > These types will be different types:
> > type I is ...;
> > type E is ...;
> > type Array1 is array (I range <>) of E;
> > type Array2 is array (I range <>) of E;
> 
> > The types Array1 and Array2 are distinct types.
> 
> And now I see. I'm still having troubles with the fact that
> "granularity" of type system in Ada can be much smaller than what can be
> achieved with structural differences only.

It's a good thing that Ada allows Array1 and Array2 above to be
different types.  But sometimes, structural typing would be better.  In
fact, Ada has moved a bit in that direction -- anonymous access types
use structural typing, more or less.

> > The next step would be getting "<" from the element type,
> > which would eliminate a need to have Sort generic.
> 
> No, I disagree. There is a place for generic subprograms, otherwise we'd
> have everything in a single hierarchy with Object at the top. It's not a
> coincidence that "other languages" drift towards supporting generics,
> even if they already had such single-rooted hierarchies.

A hierarchy with Object at the top would be a Good Thing, IMHO.  Trees
are more aesthetically pleasing than forests.  But you're right that you
still need some sort of generic facility, so you can have strongly typed
containers.  But I think perhaps we should have generic types
(i.e. parameterized types) rather than generic packages.  That's what
discriminants do, but they're severely limited.  It would make sense to
have a discriminant that is a type, so you could say:

    My_Sequence: Sequence(Element => Integer) := (1, 2, 3);

- Bob

Re: Generic procedures and their parameters

[Dmitry A. Kazakov]

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

Re: Generic procedures and their parameters

[Maciej Sobczak]

Robert A Duff wrote:

>> But then, you would need to have even such fundamental things like
>> Integer belong to Ordered'Class. It's a shaky ground.
> 
> Why is that shaky?  Integer IS ordered.

Is it also tagged? Do you want it to be? Or maybe there should be a 
special case for Integer (and its every subtype), so that it's 
semantically in Ordered'Class without being syntactically tagged?
Is it really in the spirit of Ada?

Integer is not only Ordered. It's also Summable, Subtractable, 
Multipliable, Divideable, Powerable, Incrementable, Decrementable, 
Comparable, Copyable, Assignable, Imageable and even Aspect_Clauseable, 
not mentioning Can_Be_Used_As_Array_Index. And it has some others as well.
And all this is very important, since there might be other types that 
share only some of these properties but not others and surely we don't 
want our Container_Of_Incrementable_And_Divideable_And_Comparable to 
contain something that isn't, right?

(sorry if any of the above is not proper English)

;-)

And switching back to serious, I somehow don't like languages that try 
to apply object-orientedness to absolutely everything. In C++ the fact 
that int is ordered does not require that it relates to some Ordered 
class. Such properties - if needed - can be expressed in other ways.


> A hierarchy with Object at the top would be a Good Thing, IMHO.  Trees
> are more aesthetically pleasing than forests.

Opinions vary on this subject. :-)

> But I think perhaps we should have generic types
> (i.e. parameterized types) rather than generic packages.  That's what
> discriminants do, but they're severely limited.  It would make sense to
> have a discriminant that is a type, so you could say:
> 
>     My_Sequence: Sequence(Element => Integer) := (1, 2, 3);

Yes, that would be fine.


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Generic procedures and their parameters

[Dmitry A. Kazakov]

On Wed, 06 Sep 2006 16:14:07 +0200, Maciej Sobczak wrote:

>> Why is that shaky?  Integer IS ordered.
> 
> Is it also tagged? Do you want it to be?

Not Integer, but Integer'Class.

> Integer is not only Ordered. It's also Summable, Subtractable, 
[...]

Yes, it is called multiple inheritance.

> In C++ the fact 
> that int is ordered does not require that it relates to some Ordered 
> class.

Which is unfortunate for both C++ and Ada, because "to be ordered" = "a
member of Ordered class." There is no obvious reason why they should be
different.

>> A hierarchy with Object at the top would be a Good Thing, IMHO.  Trees
>> are more aesthetically pleasing than forests.
> 
> Opinions vary on this subject. :-)

One does not exclude other. Ada provides a powerful type cloning mechanism
(I mean: type X is new Y, unfortunately not for types, which are visibly
tagged). You can take a branch and plant it as a new tree.

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

Re: Generic procedures and their parameters

[Georg Bauhaus]

On Wed, 2006-09-06 at 17:09 +0200, Dmitry A. Kazakov wrote:
> On Wed, 06 Sep 2006 16:14:07 +0200, Maciej Sobczak wrote:
> 
> >> Why is that shaky?  Integer IS ordered.
> > 
> > Is it also tagged? Do you want it to be?
> 
> Not Integer, but Integer'Class.
> 
> > Integer is not only Ordered. It's also Summable, Subtractable, 
> [...]
> 
> Yes, it is called multiple inheritance.

A {PropA,PropB,...}able Integer has multiple interfaces,
can act as any of them, etc, ok, but I think MI is inheritance
of data as well, in the vernacular. Are you perhaps thinking
of something like "aspect interfaces"?

Re: Generic procedures and their parameters

[Steve]

"Maciej Sobczak" <no.spam@no.spam.com> wrote in message 
news:edm273$fee$1@sunnews.cern.ch...
> Hi,
>
> I have found the following signature for the sorting procedure:
>
> 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?
>

I prefer:

generic
    type Index_Type is (<>);
    type Collection_Type is private;
    firstIndex : Index_Type;
    lastIndex : Index_Type;
    with function In_Order( list : Collection_Type; i, j : Index_Type ) 
return Boolean;
    procedure Swap( list : in out Collection_Type; i, j : Index_Type );
procedure Sort( list : in out Collection_Type );

This avoids the declaration of the array altogether, and is usable for any 
list that may be referenced by index.

My 2 cents.

Steve
(The Duck)

>
> -- 
> Maciej Sobczak : http://www.msobczak.com/
> Programming    : http://www.msobczak.com/prog/ 

Re: Generic procedures and their parameters

[Georg Bauhaus]

Dmitry A. Kazakov wrote:

> But this all is independent on the question whether interface and
> implementation inheritances are different things. They are not. 

Suppose I have some complex number type C
having a lengthy division operation that requires
auxiliary components in the implementation.

Now I want a type of complex numbers just like C
but without a division operation.
One way to do so might seem to inherit a D from C,
and clear the division operation,

   type C is tagged private;
   ...
   procedure division(a, b: C; result: in out C);


   type D is new C with private;
   ...
   overriding
   procedure division(a, b: D; result: in out D) is null;

(Is there anything better than null BTW? It won't remove
division from D's interface...)
This will leave the auxiliary components of C in D.

But couldn't I do better? For example, by declaring
the interface I want, and then requesting that the needed
operations be "extracted" from C, dropping the division
stuff (provided there is a way to mark components as being
needed by only some set of operations.)

I will loose view conversions to C.
But if that is what I want? Just a composition of
the interface I need in some scope?

Re: Generic procedures and their parameters

[Dmitry A. Kazakov]

On Wed, 06 Sep 2006 18:35:58 +0200, Georg Bauhaus wrote:

> On Wed, 2006-09-06 at 17:09 +0200, Dmitry A. Kazakov wrote:
>> On Wed, 06 Sep 2006 16:14:07 +0200, Maciej Sobczak wrote:
>> 
>>>> Why is that shaky?  Integer IS ordered.
>>> 
>>> Is it also tagged? Do you want it to be?
>> 
>> Not Integer, but Integer'Class.
>> 
>>> Integer is not only Ordered. It's also Summable, Subtractable, 
>> [...]
>> 
>> Yes, it is called multiple inheritance.
> 
> A {PropA,PropB,...}able Integer has multiple interfaces,
> can act as any of them, etc, ok, but I think MI is inheritance
> of data as well, in the vernacular. Are you perhaps thinking
> of something like "aspect interfaces"?

I remember it is was a buzz word 2-3 years ago. (:-))

I don't think it makes any sense to separate interface and implementation
inheritance.

OK, in practice, there might be a granularity associated with the
visibility issues. For Ada it would mean that you could publicly inherit
from an interface and privately choose whether you inherit the
implementation as well, or rather provide a completely new one. And,
reverse, you don't inherit from interface, but, privately, do from the
implementation. The later is widely used in Ada (it is type X is private;)

But this all is independent on the question whether interface and
implementation inheritances are different things. They are not. 

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

Re: Generic procedures and their parameters

[Dmitry A. Kazakov]

On Wed, 6 Sep 2006 19:47:14 -0700, Steve wrote:

> "Maciej Sobczak" <no.spam@no.spam.com> wrote in message 
> news:edm273$fee$1@sunnews.cern.ch...
>> Hi,
>>
>> I have found the following signature for the sorting procedure:
>>
>> 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?
> 
> I prefer:
> 
> generic
>     type Index_Type is (<>);
>     type Collection_Type is private;
>     firstIndex : Index_Type;
>     lastIndex : Index_Type;
>     with function In_Order( list : Collection_Type; i, j : Index_Type ) 
> return Boolean;
>     procedure Swap( list : in out Collection_Type; i, j : Index_Type );
> procedure Sort( list : in out Collection_Type );
> 
> This avoids the declaration of the array altogether, and is usable for any 
> list that may be referenced by index.

Ah, that's an "abstract generic array" thing. If more that just Sort is
needed one goes as:

generic
   type Index_Type is (<>);
   type Element_Type is private;
   Null_Element : Element_Type;
   type Collection_Type is private;
   with function First (X : Collection_Type) return Index_Type is <>;
   with function Last (X : Collection_Type) return Index_Type is <>;
   with function Get (X : Collection_Type) return Element_Type is <>;
   with procedure Set (X : in out Collection_Type; Y : Element_Type) is <>;
package Generic_Collection is
   -- Nothing here. It is an "abstract" package
end Generic_Collection;

Then Sort becomes a child:

generic
   with function "<" (Left, Right : Element_Type) return Boolean;
procedure Generic_Collection.Sort (X : in out Collection_Type);

Unfortunately, Element_Type reappears.

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

Re: Generic procedures and their parameters

[Dmitry A. Kazakov]

On Thu, 07 Sep 2006 08:48:21 +0200, Georg Bauhaus wrote:

> Dmitry A. Kazakov wrote:
> 
>> But this all is independent on the question whether interface and
>> implementation inheritances are different things. They are not. 
> 
> Suppose I have some complex number type C
> having a lengthy division operation that requires
> auxiliary components in the implementation.
> 
> Now I want a type of complex numbers just like C
> but without a division operation.

Operation disallowing, it is an interesting beast...

> One way to do so might seem to inherit a D from C,
> and clear the division operation,
> 
>    type C is tagged private;
>    ...
>    procedure division(a, b: C; result: in out C);
> 
> 
>    type D is new C with private;
>    ...
>    overriding
>    procedure division(a, b: D; result: in out D) is null;
> 
> (Is there anything better than null BTW? It won't remove
> division from D's interface...)

It cannot, because D is in C'Class. You need "/" there (minimally as a slot
in the dispatching table), otherwise some class-wide operations of C would
become erroneous. Actually "override with null" = "override with raise
Some_Error." In static cases the compiler can catch it, but in general case
it cannot, provided that T'Class exists. [And it shall, IMO, exist for all
types, maybe for T'Class itself too (:-)) ]

> This will leave the auxiliary components of C in D.
> 
> But couldn't I do better? For example, by declaring
> the interface I want, and then requesting that the needed
> operations be "extracted" from C, dropping the division
> stuff (provided there is a way to mark components as being
> needed by only some set of operations.)

This is quite straightforward. You declare somewhere an interface without
division (Ring). Then you inherit D's interface from Ring and do D's
implementation from C. That should work similarly to Ada's implementation
by renaming and matching "is <>" formal generic subprograms. So C."+" would
implement D."+" inherited from Ring."+", while C."/" will be dropped,
because there is no Ring."/". Basically, it could be just an automated
delegation.

> I will loose view conversions to C.

Publicly, privately you can still have them. It makes little sense not to
have them privately, because "/" can be still reachable. You never know, if
"+" does not call it.

> But if that is what I want? Just a composition of
> the interface I need in some scope?

View conversions and other conversions (and attributes) are in fact
primitive operations. As such they are a part of the interface. There is no
magic in, if you have a different interface, then conversions are
automatically different.

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

Re: Generic procedures and their parameters

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:w0vh1ugsvkj1$.2fnx5mt0tplm$.dlg@40tude.net...
...
> The reverse is a different story. It is a pity that Ada does not have
> attributes to get the index and element types from the array type
> (container type). The next step would be getting "<" from the element
type,
> which would eliminate a need to have Sort generic.

That doesn't really work. "<" is what controls how the items are sorted, and
it is common to want to sort the same type in multiple ways. If you have
employee records, you might want to sort them both on Social Security
numbers and on date of employment, for example. Two generic instantiations
work fine for that, but there isn't any way to have two "<" with different
behaviors.

We had this discussion when looking at the possibility of having a sorting
interface. It just doesn't work well, because there can only be a single
implementation. (That is a problem with any scheme based on inheritance.)
That's why I view interfaces less as types and more as properties that are
either present or absent on any individual specific type.

                            Randy.

Re: Generic procedures and their parameters

[Dmitry A. Kazakov]

On Thu, 7 Sep 2006 22:35:44 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:w0vh1ugsvkj1$.2fnx5mt0tplm$.dlg@40tude.net...
> ...
>> The reverse is a different story. It is a pity that Ada does not have
>> attributes to get the index and element types from the array type
>> (container type). The next step would be getting "<" from the element type,
>> which would eliminate a need to have Sort generic.
> 
> That doesn't really work. "<" is what controls how the items are sorted, and
> it is common to want to sort the same type in multiple ways. If you have
> employee records, you might want to sort them both on Social Security
> numbers and on date of employment, for example. Two generic instantiations
> work fine for that, but there isn't any way to have two "<" with different
> behaviors.
>
> We had this discussion when looking at the possibility of having a sorting
> interface. It just doesn't work well, because there can only be a single
> implementation. (That is a problem with any scheme based on inheritance.)
> That's why I view interfaces less as types and more as properties that are
> either present or absent on any individual specific type.

Yes, that's when somebody wanted to have different orders. But that in my
view is a different case, in which "<" should be better passed to Sort as a
plain parameter, rather than generic or primitive subprogram. I think the
difference between two scenarios is whether the order is arbitrary, ad-hoc
or else involved in some loose set of operations. In the first case "<"
should be a parameter in the latter case a part of the interface (be it
generic or primitive operation).

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

Re: Generic procedures and their parameters

[Maciej Sobczak]

Dmitry A. Kazakov wrote:

>> In C++ the fact 
>> that int is ordered does not require that it relates to some Ordered 
>> class.
> 
> Which is unfortunate for both C++ and Ada, because "to be ordered" = "a
> member of Ordered class." There is no obvious reason why they should be
> different.

No obvious, but subtle, yes.
Integer is Ordered, but so is String. Can you imagine a 
Sequence_Of_Ordered containing, say, 7, 123, "Dmitry", -5, "Maciej"?
All these objects are Ordered. Just like Banana is Fruit and Apple is 
Fruit, right? Still, I can imagine a container of Fruits with Bananas 
mixed with Apples, but certainly not a container of Ordered - and the 
problem is that the values listed above don't really share much in 
common. Can you sort a Sequence_Of_Ordered? No.

So - what does it really mean that Integer and String are both Ordered?

OK, I know - we forgot that their "domains" of ordering are disjoint.

But then - what's the point of having Ordered'Class?

As far as I perceive it, the fact that Banana is Fruit and the fact that 
Integer is Ordered are two facts of *different kind*. The former is 
related to the "business disctionary" (nice buzz), whereas the latter is 
more an information about the type. For me, these two facts exist on 
separate levels and should not be mixed in the same inheritance 
hierarchy. Moreover, the language should give me distinct tools to 
express these distinct kinds of facts and for example in C++ I use class 
inheritance for Banana is Fruit, but type traits for Integer is Ordered. 
If I had to express these two in the same way (and in the same 
hierarchy) I would feel a bit uncomfortable. Kind of "weak type safety 
on the meta-level".

There is another "small issue". Robert mentioned that trees are 
aesthetically pleasing. The problem is that with Ordered (Comparable, 
Summable, etc.) there is no tree any more because of massive 
proliferation of multiple inheritance that is then used to express facts 
about types. The only "pleasing" thing left in the resulting mess is 
that there are still no cycles. ;-)


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Generic procedures and their parameters

[Dmitry A. Kazakov]

On Fri, 08 Sep 2006 11:11:35 +0200, Maciej Sobczak wrote:

> Dmitry A. Kazakov wrote:
> 
>>> In C++ the fact 
>>> that int is ordered does not require that it relates to some Ordered 
>>> class.
>> 
>> Which is unfortunate for both C++ and Ada, because "to be ordered" = "a
>> member of Ordered class." There is no obvious reason why they should be
>> different.
> 
> No obvious, but subtle, yes.
> Integer is Ordered, but so is String. Can you imagine a 
> Sequence_Of_Ordered containing, say, 7, 123, "Dmitry", -5, "Maciej"?
> All these objects are Ordered. Just like Banana is Fruit and Apple is 
> Fruit, right? Still, I can imagine a container of Fruits with Bananas 
> mixed with Apples, but certainly not a container of Ordered - and the 
> problem is that the values listed above don't really share much in 
> common. Can you sort a Sequence_Of_Ordered? No.
> 
> So - what does it really mean that Integer and String are both Ordered?
> 
> OK, I know - we forgot that their "domains" of ordering are disjoint.
> 
> But then - what's the point of having Ordered'Class?

The notion of "order" is abstract, so the class Ordered should be. It is
not required to have any instances of Ordered'Class. That is no different
from other unconstrained types. You could ask what's the point in having
array (Integer range <>) of Character, if String'Last is undefined?

> As far as I perceive it, the fact that Banana is Fruit and the fact that 
> Integer is Ordered are two facts of *different kind*. The former is 
> related to the "business disctionary" (nice buzz), whereas the latter is 
> more an information about the type. For me, these two facts exist on 
> separate levels and should not be mixed in the same inheritance 
> hierarchy. Moreover, the language should give me distinct tools to 
> express these distinct kinds of facts and for example in C++ I use class 
> inheritance for Banana is Fruit, but type traits for Integer is Ordered. 
> If I had to express these two in the same way (and in the same 
> hierarchy) I would feel a bit uncomfortable. Kind of "weak type safety 
> on the meta-level".

In my view it is just the difference is between inheritance from an
interface (Ordered is an interface) and inheritance from both an interface
and an implementation of (Fruit is a concrete type). Surely the language
should allow interface-only inheritance from concrete types. So I agree
with your point about language tools, but the point is irrelevant. Because
the constraints you might wish to put on T'Class, on T'Class x T'Class, on
T'Class x T'Class x T'Class..., on T'Class x W'Class and so on, is a
different story (multimethods, multiple dispatch, parallel hierarchies and
so on). 

> There is another "small issue". Robert mentioned that trees are 
> aesthetically pleasing. The problem is that with Ordered (Comparable, 
> Summable, etc.) there is no tree any more because of massive 
> proliferation of multiple inheritance that is then used to express facts 
> about types. The only "pleasing" thing left in the resulting mess is 
> that there are still no cycles. ;-)

It is how our world was created. (:-)) But what is instead? The relations
is-ordered, is-additive-group, is-ring, is-field etc are all here. They
don't magically disappear when templates are used. They still exist
implicitly. And in Ada, you should describe them ad-hoc in a quite awkward
way of generic formal parameters. These generic specifications cannot be
re-used, composed, inherited. They cannot be checked against the things
they actually represent. In C++ it is even worse, because instead of
specifications there is only "anything the compiler might find in the
instantiation context."

In fact, it is generics, which are "meta-weakly" typed, because they don't
allow explicit specification of the meta-type Ordered, and because that
meta-type is matched by structure.

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

Re: Generic procedures and their parameters

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:g3c05xzf7uad$.wucggq0h6wuy$.dlg@40tude.net...
...
> Yes, that's when somebody wanted to have different orders. But that in my
> view is a different case, in which "<" should be better passed to Sort as
a
> plain parameter, rather than generic or primitive subprogram.

We considered that, too, and decided not to do it because it because it
doesn't work well in Ada. "<" is usually Intrinsic, and Intrinsic things
cannot be passed as access-to-subprogram parameters. So you'd have to
explicitly build a wrapper function, with all of the possibilities for error
that that exposes. Generic instantiations don't have that limitation (as
they are are considered more heavyweight than a simple 'Access).

> I think the difference between two scenarios is whether the order is
arbitrary, ad-hoc
> or else involved in some loose set of operations. In the first case "<"
> should be a parameter in the latter case a part of the interface (be it
> generic or primitive operation).

We really wanted to avoid having a lot of different sorting routines,
because that then forces users to decide which one that they need to use.
Most of the time, the choice is not particularly important (if it is not a
critical operation), and excess choices just take mental energy away from
solving the problem at hand. (That's why I'd be opposed to having multiple
kinds of lists [like doubly and singly linked] in the Ada Containers
library; the space and performance differences would be slight, but they'd
add an additional complexity to deciding what container to use.)

But you are correct that there usually is a "natural" comparison operation
and then secondary orderings -- one could consider these as different cases,
simply as one would be named "<" and the other would have some other name..

                       Randy.

Re: Generic procedures and their parameters

[Dmitry A. Kazakov]

On Fri, 8 Sep 2006 20:29:20 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:g3c05xzf7uad$.wucggq0h6wuy$.dlg@40tude.net...
> ...
>> Yes, that's when somebody wanted to have different orders. But that in my
>> view is a different case, in which "<" should be better passed to Sort as a
>> plain parameter, rather than generic or primitive subprogram.
> 
> We considered that, too, and decided not to do it because it because it
> doesn't work well in Ada. "<" is usually Intrinsic, and Intrinsic things
> cannot be passed as access-to-subprogram parameters. So you'd have to
> explicitly build a wrapper function, with all of the possibilities for error
> that that exposes. Generic instantiations don't have that limitation (as
> they are are considered more heavyweight than a simple 'Access).

Well, I never could understand why shouldn't we make procedural types and
forget all that C-ish mess with access-to-procedure.

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

Re: Generic procedures and their parameters

[Robert A Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> We considered that, too, and decided not to do it because it because it
> doesn't work well in Ada. "<" is usually Intrinsic, and Intrinsic things
> cannot be passed as access-to-subprogram parameters. So you'd have to
> explicitly build a wrapper function, with all of the possibilities for error
> that that exposes. Generic instantiations don't have that limitation (as
> they are are considered more heavyweight than a simple 'Access).

Kludgery begets more kludgery.  Surely you should be allowed to pass
things like "<" as a parameter!  Proof: see Randy's comment above.
Making wrappers should be the compiler's job.

Viewing downward closure as access values is overly implementation
oriented.  The "not null access" on the declaration, and the 'Access on
all calls, are just noise.

- Bob

Re: Generic procedures and their parameters

[Robert A Duff]

Maciej Sobczak <no.spam@no.spam.com> writes:

> Robert A Duff wrote:
> 
> >> But then, you would need to have even such fundamental things like
> >> Integer belong to Ordered'Class. It's a shaky ground.
> > Why is that shaky?  Integer IS ordered.
> 
> Is it also tagged? Do you want it to be?

Everything should be tagged.  There should be no "tagged" keyword.

But the compiler should not store the tag with every object, by default.
Tags are only needed for class-wide objects, and perhaps aliased
objects.

>...Or maybe there should be a
> special case for Integer (and its every subtype), so that it's
> semantically in Ordered'Class without being syntactically tagged?

Special-casing predefined things is usually a mistake.

Note that the rule saying 'Class only works for tagged types is not
necessary, and was not present in earlier versions of Ada 9X.
In fact, universal_integer is really root_integer'Class,
conceptually.  Too bad you can't mention its name in 
a program.

> Is it really in the spirit of Ada?

No, apparently not.

> Integer is not only Ordered. It's also Summable, Subtractable,
> Multipliable, Divideable, Powerable, Incrementable, Decrementable,
> Comparable, Copyable, Assignable, Imageable and even Aspect_Clauseable,
> not mentioning Can_Be_Used_As_Array_Index. And it has some others as
> well.
> And all this is very important, since there might be other types that
> share only some of these properties but not others and surely we don't
> want our Container_Of_Incrementable_And_Divideable_And_Comparable to
> contain something that isn't, right?
> 
> (sorry if any of the above is not proper English)
> 
> ;-)

I understood it.

Part of the problem (in most languages, including Ada) with all of the
above classes is that you have to decide up front.  It would be useful
to be able to say "type T inherits from Mungable" without modifying
the source code for T or Mungable.

> And switching back to serious, I somehow don't like languages that try
> to apply object-orientedness to absolutely everything.

Why?

Note that making everything tagged, and having a root Object type in the
hierarchy doesn't really make everything OO.  OO-ness really comes from
'Class, mainly.

>... In C++ the fact
> that int is ordered does not require that it relates to some Ordered
> class. Such properties - if needed - can be expressed in other ways.
> 
> 
> > A hierarchy with Object at the top would be a Good Thing, IMHO.  Trees
> > are more aesthetically pleasing than forests.
> 
> Opinions vary on this subject. :-)

Indeed.  ;-)

Of course, my comment about trees is somewhat bugus if multiple
inheritance is allowed.

> > But I think perhaps we should have generic types
> > (i.e. parameterized types) rather than generic packages.  That's what
> > discriminants do, but they're severely limited.  It would make sense to
> > have a discriminant that is a type, so you could say:
> >     My_Sequence: Sequence(Element => Integer) := (1, 2, 3);
> 
> Yes, that would be fine.

- Bob

Re: Generic procedures and their parameters

[Dmitry A. Kazakov]

On 09 Sep 2006 10:49:43 -0400, Robert A Duff wrote:

> Everything should be tagged.  There should be no "tagged" keyword.

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

Re: Generic procedures and their parameters

[Jeffrey R. Carter]

Robert A Duff wrote:
> 
> Note that making everything tagged, and having a root Object type in the
> hierarchy doesn't really make everything OO.  OO-ness really comes from
> 'Class, mainly.

OO-ness (object-oriented-ness) is a design attribute. You can have 
perfectly good OO-ness without type extension, dispatching, or 'Class. 
You can have it in Ada 83 or assembler. Similarly, the use of type 
extension, dispatching, or 'Class doesn't give you OO-ness. They give 
you programming by extension, which does not necessarily have anything 
to do with OO-ness.

-- 
Jeff Carter
"I blow my nose on you."
Monty Python & the Holy Grail
03

Re: Generic procedures and their parameters

[Robert A Duff]

"Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org> writes:

> Robert A Duff wrote:
> > Note that making everything tagged, and having a root Object type in
> > the
> > hierarchy doesn't really make everything OO.  OO-ness really comes from
> > 'Class, mainly.
> 
> OO-ness (object-oriented-ness) is a design attribute.

Well, yeah, that's true.  I guess I'm focusing on language features that
support OOP, as opposed to OOP itself.  And I'm deliberately ignoring
OOD and OOA, which are, to a large extent, snake oil.

>... You can have
> perfectly good OO-ness without type extension, dispatching, or
> 'Class. You can have it in Ada 83 or assembler. Similarly, the use of
> type extension, dispatching, or 'Class doesn't give you OO-ness. They
> give you programming by extension, which does not necessarily have
> anything to do with OO-ness.

I'll quibble with the Ada 83 part.  Part of OOP is the "open-closed
principle", which means you can change/extend behavior of something
without modifying its source code.  That really requires dispatching, or
something very much like it, and Ada 83 doesn't have any form of
indirect call with which to similate that.  Asssembly languages do,
though.

Of course, you can simulate (say) Smalltalk in Ada 83, and then do OOP
using that, but then that's not quite Ada programming anymore.

- Bob

Re: Generic procedures and their parameters

[Jeffrey R. Carter]

Robert A Duff wrote:
> 
> I'll quibble with the Ada 83 part.  Part of OOP is the "open-closed
> principle", which means you can change/extend behavior of something
> without modifying its source code.  That really requires dispatching, or
> something very much like it, and Ada 83 doesn't have any form of
> indirect call with which to similate that.  Asssembly languages do,
> though.

OOP is not OO. OOP is a misnomer for programming by extension, which 
does not necessarily have anything to do with OO.

-- 
Jeff Carter
"Sons of a silly person."
Monty Python & the Holy Grail
02