Re: Proposal: Auto-allocation of Indefinite Objects

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

On 10/08/2020 02:39, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:rfv3gf$1bbo$1@gioia.aioe.org...

>> I don't want the compiler deciding where Q is allocated, especially
>> because this could break things:
>>
>> 1. Large object moved to the stack
> 
> The compiler is buggy IMHO if this breaks something. Any compiler has to be
> able to deal with objects that exceed the maximum stack frame, and move
> those to somewhere that they will fit (or reject completely).
> 
> Yes, most compilers are buggy this way (including mine in a few cases). So
> what?
> 
>> 2. Lock-free code starting using heap lock when moved from the stack.
> 
> Expecting a compiler not to use the heap is silly in any case (outside of
> the No_Heap restriction - use that in Janus/Ada and the compiler refuses to
> do anything outside of elementary types). The compiler is supposed to be
> making the programmer's life easier, not adding new hurdles.
> 
>> 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.
> 
> That's the idea of such mechanisms. If you really need control, you do not
> use these abstractions and instead write the stuff yourself explicitly using
> access types and the like.

Right, that is my take on the proposal. If I am ready to compromise on 
#1 and #2, I can use an abstraction hiding pool access. Otherwise I want 
a language construct being more safe than raw access types.

> Otherwise, you use containers and unbounded strings, and they do what they
> do.

No, from the abstraction point of view they do not. They indeed abstract 
the memory allocation aspect, but they do that at the cost of 
*everything* else. Unbounded_String is no string anymore. Container is 
neither array nor record type. Unbounded_String must be converted forth 
and back. For containers I must use ugly hacks like iterators to make 
them resemble arrays and records introducing whole levels of complexity 
to fight through every time the compiler or I miss something.

In most cases I prefer to keep a clear array or record interface at the 
expense of manual memory management.

> There's no free lunch.

I think with a better type system there could be a whole banquet. (:-))

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