Re: Proposal: Auto-allocation of Indefinite Objects

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

On 29/07/2020 17:33, Brian Drummond wrote:
> On Tue, 28 Jul 2020 16:59:09 +0200, Dmitry A. Kazakov wrote:

>>>      A constant String := "done";
>>>      Q : indefinite String;
>>>    ...
>>>      loop
>>>         Q := Get_Line;
>>>         exit when Q = A;
>>>      end loop;
>>
>> I am not comfortable with the semantics of this and with possible
>> implications too. I would keep it simple.
> 
> Interesting. Can you pin down some of that discomfort? It looks simple to
> me :
> 
> "indefinite" indicates the size can vary (and the compiler knows whether
> it used the heap or stack), and in the absence of "aliased" we know there
> are no copies of the pointer (if heap).

I don't like compiler relocating objects. If the pool is a stack (or 
heap organized as a stack) it might be unable to do this.

In general, there are two close but not equivalent objectives one is 
handling indefinite components of records another is a transparent 
holder object integrated into the language (without generic mess).

Your use case is about the latter. My is rather the former.

I doubt it is possible to unite both objectives in a single AI.

>> That would be inconsistent. IMO, it should be a deep copy, provided such
>> a component would not make the type limited, of which I am not sure.
> 
> Honest question : Inconsistent with what?
> I suggested shallow copy just for simplicity, and for no (ahh) deeper
> reason. But again, I'm probably missing something.

If you make a shallow copy of

    type Node_Type is record
       Item : new Element_Type;
       Prev : Node_Ptr_Type;
       Next : Node_Ptr_Type;
    end record;

you create a dangling pointer should the original node disappear. A deep 
copy would create a new target for new Item.

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