Re: Proposal: Auto-allocation of Indefinite Objects

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

On 30/07/2020 19:04, Brian Drummond wrote:
> On Wed, 29 Jul 2020 18:20:24 +0200, Dmitry A. Kazakov wrote:
> 
>> 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.
> 
> Ah OK, I see it.
> 
> The compiler should be able to determine if (as in the loop above) the
> use of Q (the indefinite type) is equivalent to a Declare block (i.e. can
> be on the stack; new stack frame in each iteration; no relocation ever
> required) or not.

I don't want the compiler deciding where Q is allocated, especially 
because this could break things:

1. Large object moved to the stack

2. Lock-free code starting using heap lock when moved from the stack.

The mechanism should be transparent. I do not like Unbounded_String for 
many reasons. Fiddling with the heap is one of them. I do not know which 
heuristic it uses to reduce reallocation and how much extra memory it 
takes under which circumstances.

>> 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.
> 
> If a record with even one indefinite component is an indefinite record,
> and therefore embedded in a transparent holder (I like that term), aren't
> they equivalent?

I don't understand this question.

>>> 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.
> 
> You are using "new" to signify Item is indefinite, I think?
> 
> But the problem is that Prev,Next are copies of the original Prev,Next
> pointers, so if the original Node_Type is then freed, they are dangling?

They are supposed to be handled by the doubly-linked list 
infrastructure, e.g. Prev and Next pointing to the node itself is a 
precondition for freeing the node.

The problem is with the node contents.

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