Re: Generic procedures and their parameters

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

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