Re: Quick question regarding limited type return syntax

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

On Sat, 02 Aug 2014 23:35:34 +0300, Niklas Holsti wrote:

> On 14-08-02 19:56 , Dmitry A. Kazakov wrote:
>> On Sat, 02 Aug 2014 10:34:53 -0400, Robert A Duff wrote:
>> 
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>>
>>>> On Sat, 02 Aug 2014 09:20:45 -0400, Robert A Duff wrote:
>>>>
>>>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>>>>
>>>>>> ...Dispatching calls
>>>>>> through class-wide access discriminants upon initialization/finalization.
>>>>>
>>>>> Can you please give an example of what you mean?
>>>>
>>>> Components not discriminants. I had Rosen's trick in mind:
>>>>
>>>>    type T is ...
>>>>        Self : not null access T := T'Unchecked_Access;
>>>
>>> Sorry, I still don't get it.  I don't see any class-wide types or
>>> dispatching calls there.  Also, it's illegal as written (the Rosen trick
>>> is only allowed for limited types.)  Perhaps a complete compilable
>>> example would help illustrate the language anomaly you are talking
>>> about.
>> 
>> with Ada.Finalization;
>> with Ada.Text_IO;
>> procedure Test is
>>    package P is
>>       type T is new Ada.Finalization.Limited_Controlled with record
>>          Self : not null access T'Class := T'Unchecked_Access;
>>       end record;
>>       overriding procedure Initialize (X : in out T);
>>       procedure Foo (X : in out T) is null;
>>    end P;
>>    
>>    package body P is
>>       procedure Initialize (X : in out T) is
>>       begin
>>          X.Self.Foo;
>>       end Initialize;   
>>    end P;
>>    
>>    package Q is
>>       use P;
>>       type S is new T with record
>>          I : Integer;
>>       end record;
>>       overriding procedure Initialize (X : in out S);
>>       overriding procedure Foo (X : in out S);
>>    end Q;
>>    
>>    package body Q is
>>       procedure Initialize (X : in out S) is
>>       begin
>>          T (X).Initialize;
>>          X.I := 1;
>>       end Initialize;
>>       procedure Foo (X : in out S) is
>>       begin
>>          X.I := X.I + 1;
>>       end Foo;
>>    end Q;
>>    
>>    Y : Q.S;
>> begin
>>    Ada.Text_IO.Put_Line (Integer'Image (Y.I));
>> end Test;
> 
> (Dmitry, I find it quite annoying that you just dump this code on us
> without bothering to explain why you think it shows some problem in Ada.)

Sorry, but the problem was self-evident to me. Robert asked for a working
example so I scraped together one without much thinking.

> The code indeed accesses an uninitialized datum: when Y is initialized,
> Initialize (S) calls Initialize (T), which makes a dispatching call to
> Foo (S), which accesses the component S.I, which is not yet initialized.

The code prematurely dispatches on an not yet initialized object. Again, it
was evident that this would happen when having a class-wide accessible in
Initialize when the parent's Initialize is to be called at the beginning of
the derived type Initialize.

> The flow of control in the example is a bit sneaky, but the
> self-referring component T.Self is in no way essential to the
> sneakiness; the same could be achieved by simply making a redispatching
> call to Foo in Initialize(T).

Yes, but as you probably remember, re-dispatching is already damned as
inconsistent regardless initialization.

> There are many other ways to create even sneakier flow of control with
> even more obscure opportunities for accessing uninitialized data.

There is no safe way to do initialization in Ada because it is not properly
typed. You should not be able to dispatch until the class-wide instance is
fully initialized, but you can because types are broken.

> Perhaps you have some personal design and coding rules which would
> prevent access to uninitialized data except for the kind of code shown
> in the example? That is, perhaps the ability to write such code in Ada
> breaks the safety of your design and coding rules? Perhaps the rule is
> that the Initialize operation of a derived type should first call
> Initialize on the parent type, and only then initialize the components
> added in the derivation (the extension components)? That is not a bad
> rule, but combining it with (re-)dispatching calls to operations
> overridden in the derived type obviously invites errors of the kind
> shown in the example.

The problem is with the semantics of Initialize, with its types.

1. IF Initialize does the specific type THEN it cannot dispatch AND it must
be through before any derived type's Initialize.

2. IF Initialize does class-wide type THEN it can dispatch AND must be
called after derived type's initialization.

It is sometimes one, sometimes another, sometimes both. It is a mess. Note
that there is a similar problem with constraints (with type invariants,
more generally):

   type Not_Working is
       Ref : not null access Something;
   end record;

This does not work for the same reason. There is no constructor which would
see Not_Working.Ref not yet initialized (without the constraint, when type
invariant not in place). Compare this with a class-wide access component to
itself. There is no constructor of the type itself which would see it not
initialized.

In both cases there can be a second level initialization where the
offending component is fully operational. But it cannot be both. Both means
types broken.

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