Re: Ada Annoyances

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

On 17-06-26 02:43 , Randy Brukardt wrote:
> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message
> news:4921bd4e-3827-a7ac-7f2d-d60edbc514a3@tidorum.invalid...
>> On 17-06-23 20:49 , Randy Brukardt wrote:
>>> <raph.amiard@gmail.com> wrote in message
>>> news:be1619b4-2220-4287-8e67-1af32377d3f7@googlegroups.com...
>>> ...
>>>> Ada forcing tagged types on you to use certain features *is* a
>>>> problem, if only because certain Ada users are forbidden to
>>>> use tagged types altogether and thus are prevented to use a
>>>> lot of useful features.
>>>
>>> Stupid language usage rules are not the problem of the language design,
>>> they're a management problem.
>>
>> Sometimes usage rules are imposed by environment constraints, in
>> particular limited resources in smallish embedded systems, combined with
>> reliability requirements which mean that running out of resources at run
>> time must be avoided.
>>
>>> I can understand banning T'Class (thus banning
>>> dynamic dispatching) and banning controlled types (thus banning hidden
>>> calls
>>> that can be harder to analyze), but not banning tagged types themselves.
> ...
>
>> b) the non-static size of class-wide objects (of type T'Class), which
>> means that the compiler and/or the programmer must use dynamic allocation
>> (usually heap or secondary stack) for such objects.
> ...
>> Point (b) is more difficult and I know of no work-around that can be
>> applied at analysis time.
>
> Simply banning the use of T'Class has that effect.

At design and compilation time, yes, with consequent restrictions on the 
design. But it is not a work-around that allows static analysis of 
programs which do use T'Class.

> It's rather drastic, but
> it eliminates all of the dynamic features. Note that this was considered
> important enough that the standard (in Annex H) restriction No_Dispatch has
> this effect.
>
> You still get the other advantages of tagged types (extension, proper
> inheritance for private, equality, prefixed notation, etc.), and there is
> almost no runtime penalty (or analysis problem).

For the application I most have in mind (a SW component currently using 
discriminated records to simulate tagged types) there would be no point 
in using tagged types with the No_Dispatch restriction. The loss of 
class-wide programming and class-wide data structures would remove 
almost all benefits.

My hope is that a Maximum_Size aspect would let one manipulate 
class-wide objects in the same "definite" way as is possible for variant 
records with a default discriminant value. However, it would require 
that the tag of an object could be changed by assignment; this is 
perhaps too radical a change in the tagged object semantics.

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