Re: What would you like in Ada202X?

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

On Mon, 07 May 2012 00:26:52 +0300, Niklas Holsti wrote:

> On 12-05-06 22:28 , Dmitry A. Kazakov wrote:
>>
>> Yes, for tagged types operations which are unsafe to inherit are inherited
>> abstract, e.g. functions returning covariant value.
> 
> The same could be done also for extension by deepening, but it is not 
> needed, as long as we don't introduce tags and class-wide programming 
> for these types. Inheriting these operations as abstract could even be 
> inconvenient, since it would force the program to implement (override) 
> the operations even when they are not needed.

What are you going to do with user-defined operations?

In the model (1) where the derived type is a subtype (in Ada sense) they
get automatically inherited in any context where visible. [This in effect
makes you exposed to "class-wide" programming with subtypes even if you
don't want to. All subtypes of a type form a class with ad-hoc operations
gathered from all members, when visible.]

In the tagged model (2) the derived type is independent and any specific
operations of the parent are dropped.

>> This looks like plain interface inheritance. You inherit the interface (the
>> literals of the type) dropping the implementation (encoding).
> 
> Not quite, because the derived type does not inherit the literals that 
> are refined. Detailed_Message_Kind does not have the literals Request 
> and Reply, because they have been refined into the literals Read and 
> Write, and into the literals Data, Ack, and Refused, respectively.

OK, +operation disallowing. This would not work in the model #1.

(I guess that difficulties with enumeration extension proposals stem from
attempts to force it under the model #1)

>> Parent's
>> operations are inherited per composition with a type conversion.
> 
> Yep.
> 
>> I always wished to have this mechanism in Ada. Note that instead of
>> inventing some complicated syntax which purpose is basically to generate
>> conversion functions (four conversions are needed in most general case),
>> you should just allow the programmer to define them by himself.
> 
> There is a trade-off. Using syntax constrains the kinds of conversions 
> the programmer can use, which may help compilation and code generation. 
> Programmer-defined unrestricted conversion functions could become too 
> complex for efficient compilation.

Possibly, though a more general construct would reduce the number of cases
the compiler designer should go though. I think that combinatorial
explosion of variants could be a bigger problem for the optimizer.

>> My opinion is that the language should provide very few fundamental
>> primitives rather than a forest of special cases.
> 
> I agree, in theory. In practice, it is difficult, even if you could 
> define a language from scratch.

Yes. More general constructs have more power, which needs to be carefully
constrained in order to keep the language safe. C and PL/1 give us examples
of the damage type conversions may inflict.

> It is even more difficult for Ada 
> because of the compatibility requirements.

On the contrary, it is rather specific extensions which likely are to
become incompatible. Generalizations are less problematic, you simply
define old constructs in new terms.

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