Re: What would you like in Ada202X?

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

On 12-05-07 10:49 , Dmitry A. Kazakov wrote:
> 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?

As distinct from what? Predefined operations? Why should there be any 
difference?

> In the model (1) where the derived type is a subtype (in Ada sense)

I'm afraid I don't understand, sorry. Are you talking about Ada 
"subtype" declarations? They are not "derived types" in the Ada sense.

My suggestion for derived enumeration types that extend the parent type 
(by "deepening") would create derived types (in the Ada sense), not 
subtypes (in the Ada sense). Thus any user-defined (primitive) 
operations for the parent type (except those with "out" parameters of 
that type, as already discussed) would be inherited (redeclared) for the 
derived type and implemented with automatic conversion of "in" parameters.

> 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.]

Could you give an example, preferably using the types Message_Kind1 and 
Detailed_Message_Kind?

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

Ditto, example please, in this context?

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

Could be - some discussion in AI95-261 suggests a new reserved word 
"supertype", the reverse of "subtype" - but the main text of the AI uses 
"type .. is new ..", making a derived type and not a subtype (both words 
in the Ada sense).

>>> 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.

Especially *implicit* type conversions. Vide C++ ... it is interesting 
to see that even there, forcing explicit conversion is gaining favour.

>> 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.

If possible! I fear that the "old constructs" in Ada each have their own 
small, thorny features, carefully defined, for example to avoid specific 
kinds of distributed overhead, or to spare some implementor from having 
to make major changes in his/her compiler. While one could likely make a 
good approximation of the old features by combining new, fundamental 
primitives, getting all these small details exactly right would be 
difficult, and failing there would break compatibility.

However, it would be nice to see this attempted, sooner or later, and 
perhaps the incompatibility could be tolerated.

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