Re: Ada Annoyances

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

(Apologies for a delayed reply.)

On 17-06-30 00:12 , Robert A Duff wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>
>> There are two reasons why tagged types hamper such analysis:
>
> As Randy pointed out, it is more correct to say that class-wide types do
> that.  Tagged types by themselves do not cause these problems.
> Tagged types without class-wide types are not super useful,
> but they are somewhat useful.
>
>> 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.
> ...
>> 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;
>
> Something like that was considered and rejected for Ada 9X.
> Part of the problem is that it seems so low level to be talking
> about sizes.  It's not even portable.

You are right, but this feature would be used only or mainly in embedded 
programs, which usually already contain unportable, low-level stuff: 
task stack sizes, record representation clauses, etc.

> And not maintainable -- if you
> delete a big type, or make it smaller, you're now wasting space.

If the feature would be adopted, I imagine a friendly compiler would (at 
least optionally) tell me that I am wasting space, or that the given 
Maximum_Size is too small, and what would be the minimum valid value (as 
GNAT does now for 'Size clauses that give a too-small size) even if it 
requires some bind-time or link-time global check. That is a 
quality-of-implementation issue.

> It would be better to have the compiler compute the maximum
> size needed.  That  would require the compiler to do a fairly
> global analysis, which is something Ada compilers are not
> set up to do.

Well, the "binder" part of the compilation system does some global 
stuff. And I would not be surprised if link-time "relocation"-type 
computations could be (mis-)used to compute the maximum size of any type 
in a class.

Some compilers already support stack-size analysis, which is a similar 
global analysis.

>>    type Object_List is array (List_Index) of Root'Class;
>>
>>    type Object_Pair is record
>>       A, B : Root'Class;
>>    end record;
>
> Would you allow:
>
>     X : Object_List (1..10);
>     Y : Object_Pair;
>
> ?

I would like to allow that (default initialized components of type 
Root'Class), but I would not much mind having to initialize such 
components explicitly.

> If so, what is the 'Tag of the various components?
> "Undefined" is not a very satisfying answer.

I agree that "undefined" would not be good. The natural answer seems to 
be that the default initial tag is that of the Root type, but then we 
must assume that it is not an abstract type.

> These things are analogous to records with defaulted discriminants.

Yes, that has been my mental model (and it is the implementation used in 
the main SW component that I would like to switch over to class-wide types).

> The language makes some (unsuccessful!) attempt to prevent
> uninitialized discriminants.

Interesting -- I did not know that the attempt is not fully successful. 
Is it easy to explain when the attemp fails?

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