Re: Ada Annoyances

[Niklas Holsti <niklas.holsti@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.

I have so far avoided using tagged types in my embedded applications 
because they indeed hamper the discovery of resource usage (execution 
time and stack space) by static analysis, as you said.

There are two reasons why tagged types hamper such analysis:

a) dispatching calls (as you said), where the actual callee is 
determined by run-time values (tags) which are hard to predict by static 
analysis

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 (a) can be worked around: static analysis tools usually let the 
analyst specify the possible set of callees for a "dynamic call" (of 
which dispatching calls are one kind) and the analysis can then 
encompass all those callees. (Alternatively, the analysis tool can 
extract the class hierarchy from the debugging information, and itself 
discover the possible callees.)

Point (b) is more difficult and I know of no work-around that can be 
applied at analysis time.

For some time, I have had in mind a possible Ada extension to solve 
point (b): an attribute/aspect that would let the programmer set a 
static upper bound on the size of any object in T'Class. If we call this 
aspect Maximum_Size (or perhaps Maximum_Size'Class), the programmer 
could use it like this:

    type Root is tagged record ... end record
    with Maximum_Size => 128;

    type Child is new Root with record ... end record;
    -- The compiler checks that Child'Size is at most 128 bits, and
    -- rejects the program otherwise.

It would now be legal to create statically sized data structures using 
Root'Class, without dynamic memory allocation, by allocating 128 bits 
for each value of type Root'Class:

    type Object_List is array (List_Index) of Root'Class;

    type Object_Pair is record
       A, B : Root'Class;
    end record;

and so on.

With this extension, or some other means to solve point (b), I would 
start using tagged types in embedded SW. For example, I have a major SW 
component, used in several projects, which simulates a class hierarchy 
with variant records and case statements. This component would be 
greatly improved by using a tagged type instead, but it would need data 
structures with class-wide components of static (maximum) size.

What do people think of a Maximum_Size aspect? Should I consider writing 
a formal suggestion to ada-comment?

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