Re: Proposal: Auto-allocation of Indefinite Objects

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:rfs7k4$c83$1@gioia.aioe.org...
> 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.

This is not that hard to deal with. Janus/Ada handles discriminant-dependent 
components of mutable objects this way: they are allocated on the stack, but 
if they have to be reallocated they move to the heap.

I note that the original idea already exists for discriminant-dependent 
components -- that's a bit more painful to use but hardly difficult. The 
main issue is that most compilers fail to support these components properly, 
using some sort of max-size implementation unconditionally rather than 
switching to a pool-based implementation when the max size is too large. 
I've never understood why Ada compilers were allowed to make such a 
limitation (it becomes a major limitation when working on non-embedded 
programs), while similar limitations on case statements and aggregates are 
not allowed.

                                         Randy.