Re: What would you like in Ada202X?

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 12-05-09 11:02 , Dmitry A. Kazakov wrote:
> On Tue, 08 May 2012 22:20:21 +0300, Niklas Holsti wrote:
>>
>> Perhaps the derived "deepened" type could inherit operations with "out"
>> and "in out" parameters of the parent type if these parameters were kept
>> as parent type, and not mapped to the derived type
>
> No, they must be inherited exactly same way

"Must" by which authority?

> parameter of derived type when inherited, that is covariance. When an in
> operation is inherited it too has the parameter of the derived type, which
> is then converted and passed to the inherited body. For out-operations you
> call the inherited body and then convert the result. For in-outs, you
> convert-in, call, convert-out.
>
> You might mean that composition with conversion could be inappropriate
> here.

For result values ("out", "in out", "return") conversion is 
inappropriate because there is no natural conversion in that direction.

>>> This would exclude all functions returning values of the type. In
>>> particular T'Val, T'Succ, T'Pred. Are you going to define some of them new?
>>
>> Of course the derived "deepened" type must have these operations, since
>> it is an enumeration type,
>
> (See how quickly multiple inheritance slips in? (:-))

Only in your wide view of what "multiple inheritance" means :-]

> This is why it makes no sense to implement it for specifically enumeration
> types. The disadvantages it may have (rather imaginary ones, IMO) will all
> be yours. So why not to face it, and just do it for all types. Sorry for
> advocating this for years, but there is no other way.

I wish you would write up your proposal in a self-contained form. Yes, 
you have been advocating this, but in scattered postings, and so 
sketchily that it has not IMO been possible to understand and discuss it.

> You will have to solve MD problematic as well. E.g.
>
>     type T1 is (...);
>     type T2 is (...);
>     procedure D (X : T1; Y : T2);

- Declaration 1: D (T1, T2).
>
>     type S1 is new T1 with ...;

Inheritance from declaration 1 gives:

- Declaration 2: D (S1, T2).

>     type S2 is new T2 with ...;

Inheritance from declaration 1 gives:

- Declaration 3: D (T1, S2).

Inheritance from declaration 2 gives:

- Declaration 4: D (S1, S2).

>     X1 : T1;
>     X2 : S1;
>     Y1 : T2;
>     Y2 : S2;
> begin
>      D (X2, Y1); -- Illegal?

This is D (S1, T2), legal by declaration 2.

>      D (X1, Y2); -- Legal but Constraint_Error (Ada 95 hack)

This is D (T1, S2), legal by declaration 3.

Sorry, which "Ada 95 hack" do you mean?

> Semantically, there always will be some issue with conversions, because any
> non-trivial modification of a type, must break something. If it did not,
> you would use the old type instead.

Yes. Tagged types get around that by using view conversions. But that is 
only possible because a value of a derived tagged type in effect 
contains a value of the parent type, which is independent of the other 
components that were added in the derivation. The parent-type value can 
therefore be changed (by "out" or "in out") without considering the 
added components.

This is not possible for the "deepened" enumeration types.

> It is not the language business, it is
> up to the programmer to resolve. The language should simply refuse to
> automate suspicious cases forcing the programmer to intervene.

In that case, it seems the language would have to be extended further, 
to let programmers write conversion functions that can convert not only 
values, but also "views" of some kind.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .