Re: Ada Successor Language

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

On 2018-06-26 22:49, Niklas Holsti wrote:
> On 18-06-26 23:16 , J-P. Rosen wrote:
>> Le 25/06/2018 à 16:03, Niklas Holsti a écrit :
>>> 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.)
>> You can achieve exactly this with a tagged type and Restriction
>> (No_Dispatch)
> 
> Not exactly that, no: you would still have to declare the types as 
> tagged, and the objects of these types would still have to store the tag 
> value somewhere, at least for use when X'Tag is taken for a controlling 
> parameter X of an inherited (non-overridden) operation.
> 
> Moreover, Restriction (No_Dispatch) is partition-wide (or so I believe, 
> because "tailored" run-time systems are mentioned in that part of the 
> RM, H.4). Thus it would not let one use both tagged record extensions 
> and untagged record extensions in the same program partition.
> 
> In fact the only similarity I can see between Restriction (No_Dispatch) 
> and the suggested extensibility of non-tagged records is that the latter 
> (as I suggested it) would also not allow dispatching -- but preventing 
> dispatch was not the point of the suggestion.
> 
> Combining extension of untagged records with Dmitry's suggestion for 
> untagged class-wide types would allow dispatch (but not re-dispatch) for 
> such extensions, which IMO shows that Restriction (No_Dispatch) is 
> independent of untagged record extensions.

Furthermore, it must not be limited to only record types or only 
extensions. Since by-reference semantics and view conversions do not 
hold for non-tagged types anyway, we could allow representation 
overriding as an alternative to representation extension.

With representation overriding the derived type must provide value 
conversions used for inherited operations. The parent type's value is no 
longer a part of the descendant's value. That will give us extending and 
shrinking enumeration types, making Unbounded_String a descendant of 
String and much more.

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