Re: How come Ada isn't more popular?

[Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sat, 03 Feb 2007 15:16:21 +0100, Markus E Leypold wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> On Fri, 02 Feb 2007 13:34:21 +0100, Markus E Leypold wrote:
>>>
>>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>>> 
>>>>> Sure you can:
>>>>>
>>>>> type Additive is abstract;  -- Should be enough for an interface
>>>>> function "+" (A, B : Additive) return Additive is abstract;
>>>>>
>>>>> Here I am not sure about "increment" variable, because it is not
>>>>> initialized. Anyway:
>>>>>
>>>>> function Increment return Additive is abstract;
>>>>>    -- Better be getter/setter pair. Unfortunately Ada does not have
>>>>>    -- "abstract variable interface" it should have
>>>>>
>>>>> function Inc (Arg : Additive'Class) return Additive'Class is
>>>>> begin
>>>>>    return Increment + Arg;
>>>>> end Inc;
>>>>>
>>>>> There is a very simple rule for all this:
>>>>>
>>>>> 1. Formal generic subroutines -> abstract primitive operations
>>>>> 2. Subroutines in the body -> class-wide operations.
>>>> 
>>>> So you derive from Additive to get a specific implementation?
>>>> 
>>>> Like
>>>> 
>>>>   type Vector   is Additive with ...;
>>>>   type CountVal is Additive with ...;
>>>> 
>>>> Right? But then, you should note that with
>>>> 
>>>>   C: Countval;
>>>> 
>>>>   Inc(C).
>>>> 
>>>> returns an 'Additive', not a 'CountVal'.
>>>
>>> No, it does Additive'Class! Thus, no problem.
>> 
>> I've been expressing myself sloppily. It should return a CountVal, not
>> an Additive'Class. CountVal(s) could not be added to Vectors -- there
>> is a difference.
>
> When Inc returns CountVal then it is not a member of Additive in the
> result. So you cannot reuse the result for other members of Additive.

Exactly. So it should not return Additive'Class (which can be added to
other members of Additive'Class), but must return CountVal to prevent
this. But since you said

>>> No, it does Additive'Class! Thus, no problem.

that means your approach fails. Do you see the different type
structure the approach using generics produces as compared to your
class inheritance approach?


>>> (note that the goal was polymorphic Inc, if you wanted it covariant that
>> 
>> No. The goal was to have mechanism to write the algorithms once and
>> being able to pull various actual operators/procedures from that
>> without replicating the specification of the algorithm.
>
> If you want to reuse Inc's algorithm in various specific Inc, then you
> would use wrappers:

No I wouldn't. At the most I'd want to instantiate one generic. See:
We are not talking about one procedure. In general we are talking
about whole libraries (i.e. BTree manipulation and search) which
contain -- in extremis -- 10 to hundred procedures, and I certainly do
NOT want to wrap all of them for every new instance differently typed
instance of the problem.


> function Common_Inc (Arg : Additive'Class) return Additive'Class is
> begin
>    return Increment + Arg;
> end Common_Inc;
> function Inc (Arg : Additive) return Additive is abstract;
>
> function Inc (Arg : CountVal) return CountVal is
> begin
>    return CountVal (Common_Inc (Arg));
> end Inc;
>
> However I don't understand the reason, why.

Look at the vector space example.


>> Let me suggest 1 other example for the usefulness of generics and than
>> 1 example where generics (Ada-style) help, but parametric polymorphism
>> (what I have been talking about as parametrized types) would actually
>> bring an advantage.
>> 
>> Example 1:
>> 
>>   An abstract vector space is defined as a sets of vectors u,v,w,...
>>   and scalars a,b,c, ...  with a number of operations:
>>    
>>     - scalars are a field, i.e. have additions an multiplication with certain properties
>>     - there is amultiplication between scalars and vectors: a*v
>>     - there is an addition between vectors.
>> 
>>   A normalized vector space introduces the idea of distance between
>>   verctors, Again certain laws apply. For the programmer: There is a
>>   dist-functions which takes 2 vectors a parameters.
>> 
>>   You can do a really huge amount of mathematics with this
>>   axioms. Examples of vector spaces with thos properties would be
>>   certain subsets of functions, finite vectors (i.e. arrays of N
>>   components), polynomes, etc.
>> 
>>   One application would be, given a function on the vector space f : V
>>   -> Real_Numbers to find minima of this function.
>> 
>>   There is an algorithm that is not very efficient but works in a vast
>>   number of cases without having to use specific knowledge of the
>>   underlying vector space.
>> 
>> With Ada generics I'd define the vector space interface a generic and
>> instantiate accordingly. The algorithm to fin minima would be
>> implemented as generic and take a vector space package as generic
>> parameter.


> I am deeply unsatisfied with generics here, because this example is almost
> exactly what I am doing. I have:
>
> Over a real domain I have:
>
> 1. Scalars
> 2. Intervals
> 3. Fuzzy numbers with a partly linear membership function
> 4. Fuzzy numbers with membership function of a nested intervals
>     + algebra of 1, 2, 3, 4 and between them
>
> But that is not all:
> 5. Sets of 3
>    + lattice over it
>
> Not yet:
>
> 6. Dimensioned scalars
> 7. Dimensioned intervals
>     + algebra
> ...
> n. Sets of dimensioned numbers
>    + lattice over it
>    + algebra between dimensioned things and scalars
> ...
> n+1 String I/O for all of them
>    + names for the members of the sets
> ...
> n+m+1 GTK widgets for them
> ...

> Should I show you generic specifications of this mess? 

And it does become better with OO? I doubt that very much. Indeed the
trick is, not to have n+m+1 instances but package instances of
generics into libraries and instantiate whole "world" in one
stroke. Have a look into the Booch components as an example.

> Can you imagine the instantiations chain from Float down to GTK+
> widget (provided your GNAT would be able to eat it (:-()? I can give
> you a link...

I have solved similar "problems". So, thanks, no.

> I DON"T want it. I need a clean way to describe an algebra and a lattice
> and then mix and bend them as I want. 

I doubt OO is the way. And whereas the Ada generics are somewhat
cumbersome (as compared with parametric polymorphism + functors + type
inference, which George doesn't like), they are your best way out of
this mess if you don't want to use a ML-like type system. They are,
indeed, good. 

> I want to be able to derive everything from a scalar. There is
> always much talk about how mathematical are generics and FP, it is
> amazing to me how readily people believe in that.

So they are wrong? :-)) Perhaps a big conspiracy, like the big C/C++
conspiracy and the big Java conspiracy.

People, you make me laugh. Isn't it avantgarde enough just to use Ada?
Must everyone else in this world be a misguided moron or an evil
propagandist?



>> Example 2
>> 
>>   Write a quicksort algorithm on arrays which can be reused for arrays
>>   of almost arbitrary elements, if a suitable order relationship is
>>   defined. Note that I might want to sort _the same_ elements with
>>   different orders (like insurance number or alphabetically ...).
>

> No problem [with some extensions to Ada types system]. 

A yes, certainly. They are already here thos extension. Their name is
-- da da da daaamm! -- generics!!!

> You need two interfaces: Array and Weakly_Ordered. 

Which forced me to use tagged type all day long and all the way, where
simply traditional array access would suffice. Let's have a look at
verifiability: I'm sure, generics can be verified better and easier. I
heard something about tagged types being really out in that sector,
and by the way, I agree. The dispatch over 13 subclasses mess
"patterns" introduce is just spagetthi programming with a big
name. (Not to disparage pattern, but making something OO doesn't make
it modular or structured per se).

> You could also sort same elements of same container object using
> different orders. [However usually in such cases one better uses a
> sorted view, rather than physically sorts.

That you can do, but I still could just sort accesses to the
elements. Withou the OO mess.


>> Yes. But Georg used generics, so it worked. You said, you don't want
>> generics, but it doesn't work. I fail to see, how George has to use
>> select an example that makes your misguided hypothesis -- that
>> generics are not neeeded -- hold up. Quite the opposite.


> generic
>    type Element is private;
>    with function "<" (Left, Right : Element)  return Boolean;
>    with function "=" (Left, Right : Element)  return Boolean;
>    type Container ...
> procedure Quick_Sort (...);

> How can this can sort the same container?

Which "same container"?

> This is a clear case where
> generics don't work. 

 Have you recently had a look to Ada.Containers? There is a generic array sort. So? 
 And BTW, you don't need "=".

> You need "<" and "=" be passed as proper functions
> rather than formal generic functions. [It is not static polymorphism
> anymore.]

And, what is the problem with that.

>> As an software engineer I'd always prefer
>> generics, since they avoid polymorphism where no polymorphism is
>> required or intended.
>
> ? Generics = static polymorphism.

No. Query negative response indicated. READY> [].

Regards -- Markus