Re: Ada Successor Language

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

On 18-06-25 15:41 , J-P. Rosen wrote:
> Le 25/06/2018 à 10:58, Alejandro R. Mosteo a écrit :
>> See this one, which is the case that bit me recently:
>>
>> procedure Blah is
>>     generic
>>         type Something is private;
>>     package Duh is
>>         type Meh is new Something;
>>     end Duh;
>>
>>     type Oh is tagged null record;
>>
>>     package Ouch is new Duh (Oh);
>>
>> begin
>>    null;
>> end Blah;
>
> A private formal allows tagged and untagged types. However, deriving
> without extension is legal only for untagged types.

So it says in RM 3.4(5/2), but even the Annotated RM has no motivation 
for it, and I don't see why Ada could not assume a null extension when 
the type is tagged. Can someone explain why the RM is so strict on this?

(In fact, it seems to me that Ada could allow untagged record extensions 
as well; the effect would be the same as for tagged ones, but no 'Class 
would be formed, and no class-wide programming or dynamic dispatch could 
be used, so all such types would be static. It would be semantically 
equivalent to aggregation of a component of the parent type with the 
extension components, but would allow direct access to the inherited 
components from the parent type. This could be a useful separation of 
extensions from tags.)

> Since it is a
> specification (that you are supposed to have read), the compiler assumes
> the best and allows the derivation. When you instantiate with a tagged
> type, you would be doing something illegal and the instantiation is not
> allowed.
>
> The same derivation would not compile in the body of the generic, where
> the worst is assumed.

But it does compile in the body, at least with my GNAT. And ARM 
3.4(5.e/2) explains: "Note that this is legal in the private part or 
body of an instance, both to avoid a contract model violation, and 
because no code that can see that the type is actually tagged can also 
see the derived type declaration."

By the way, it seems to me that the Ramification ARM 3.4(5.b/2) is wrong 
to refer to the "only if" part of the rule in 5/2, and should instead 
refer to the "if" part of the rule, which is the part that is violated 
in the ARM example (which is the same as the example being discussed here).

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