Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

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

On Wed, 6 Oct 2004 19:20:29 +0200, Robert Kawulak wrote:

>> But why an ordered list should not
>> implement an array interface? In my view it should, making the above legal
>> for lists.
> 
>   I think this is a wrong way - list is not a kind of array to implement its 
> interface. But both list and vector are *containers*, and they both have the 
> common container interface - and that's why std::for_each and other std lib 
> algorithms work on any conatiner (be it std::list, std::vector, C-style 
> array or a user-defined type).

In my view, array is a container and container is an abstract array.
Iterators should be introduced as index types, subdivided into ordered and
unordered ones. For ordered index types you can have ranges. From index
types you can build tuples, which depending on whether indices are ordered
or not, should allow subranges, projections (diagonals etc). Upon tuples
and element types one can build arrays. Subtyping of array types should
allow constraining/deriving of both index and element types.

>>>> Far less flexible you mean.
>>>
>>>     C++ doesn't have a single-rooted object hierarchy. So if containers
>>> weren't templates, they'd have to contain elements of some abstract
>>> class,
>>> call it CElement. Now, if you want to have a container of elements of
>>> some
>>> class not derived from CElement or even a container of int, then you'd
>>> have
>>> to make some wrapper classes - this would cost you a lot of time to make
>>> it
>>> work with the library.
>>
>> Yes, unless:
>>
>> 1. (for new types) language supports multiple interface inheritance. C++
>> does, Ada 2005 will.
> 
>   'elements of some class -=#not#=- derived from CElement' - I meant if you
> can derive, then there's no problem.

Yes, but differently to C++ in Ada that would cover almost 90% of all
cases. The reason is that in Ada we routinely clone/derive predefined
types:

type Velocity is new Float; -- Clone
type Velocity_Array is array ... of Velocity;

If we do it anyway, then it costs nothing to add a clause requiring
Velocity to implement, say, Comparable. Moreover, the predefined Float type
should be Comparable anyway!

>> 2. (for existing types) language supports supertyping. If it does, then
>> creating a wrapper will be a matter of one or two code lines. You create a
>> helper type which is both a subtype of CElement and a supertype of int.
> 
>   And you see, that's the point. I wrote: 'to make it work', and it's
> not as easy as it seems. In order to work with container algorithms and
> cooperate with other containers, your wrapper should also implement wrappers
> for wrapped type's iterators with wrappers for wrapped type's iterators'
> functions... Doesn't look to me like 'a matter of one or two code lines' ;-)

It is not different from the generic way. Your element should have some
operations. In C++ it is checked upon inlining. In Ada it is checked upon
instantiation. With my proposal it will be checked when you create a
wrapper. The only difference is in the place and time.

>>> If you have a function template copying elements of
>>> one container into another, then it'll work fine even for 100 container
>>> types, as long as they use the same interface.
>>
>> Which interface you mean? string is an instance of another template. It is
>> not vector<>, and there is no way to make it conform to vector<>, because
>> there is no such thing as "vector interface".
> 
>   *container* interface. String is not exactly a vector, but might be
> treated similarily to one because of it's container-like interface.

1. Who and how guaranties that? 2. You cannot have a conform to the
interface object without specifying its concrete type. The rest follows
from that.

>>> Can you specify what do you mean when saying 'mix them'?
>>
>> All cases were:
>>
>> template <class A, class B> Foo (vector <A>& X, vector <B>& Y)
>> {
>>   ...
>>   Do_Something (X [I], Y [J]);
>>   ...
>> }
>>
>> cannot be replaced with:
>>
>> template <class A> Foo (vector <A>& X, vector <A>& Y)
>> {
>>   ...
>>   Do_Something (X [I], Y [J]);
>>   ...
>> }
> 
>   Wouldn't this do?
> 
> template <class A, class B> Foo (A & X, B & Y)
> {
>   ...
>   Do_Something (X [I], Y [J]);
>   ...
> }

Where is any difference? You still have to specify both class A and class B
in the template parameter profile. Whereas the elements types are of little
interest for Foo. The contract of Foo is:

1. Foo takes two arrays as parameters.
2.a Nothing is said whether indices or elements types are related.
2.c They are members of some type set
  2.c.1 They have a common ancestor = the set is dynamically polymorphic
    2.c.1.a One is a subtype of another
  2.c.2 The set is generic = statically polymorphic
  ----
[ 2.c is equivalent, in my view, to requiring arrays to be from some set
  of types narrower than just ARRAY. If the language allows to specify
  ARRAY, then it will be also no problem to define its constrained subsets.
]
2.d They are same types

With templates you can reasonable implement only 2.d. Of course, one could
extend templates to support some sophisticated type pattern matching
mechanism, add constraints on formal types etc. IMO, that would be wasting
of time. I believe that inheritance is a much more clearer and safer way of
defining type sets than loose parametrization.

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