From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org>
Newsgroups: comp.lang.ada
Subject: Re: Proposal: Auto-allocation of Indefinite Objects
Date: Sat, 4 Apr 2020 12:54:44 +0200
Organization: Also freenews.netfront.net; news.tornevall.net;
 news.eternal-september.org
Message-ID: <r69p1k$tei$1@dont-email.me>
References: <94a54092-a56f-4a99-aaec-08dd611c8fd8@googlegroups.com>
 <7d0c6237-da84-4d48-8aa4-764b747975be@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 4 Apr 2020 10:54:44 -0000 (UTC)
Injection-Info: reader02.eternal-september.org;
 posting-host="6ac9d8736f43faaf1fa680b4910ab252";
	logging-data="30162"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1+JgRk1xhcobW4YqgLxEAsf64yhLW9yGaY="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
Cancel-Lock: sha1:TkQX/E83+7dFEJPYd18VAxRGMlo=
In-Reply-To: <7d0c6237-da84-4d48-8aa4-764b747975be@googlegroups.com>
Content-Language: en-US
Xref: reader01.eternal-september.org comp.lang.ada:58314
Date: 2020-04-04T12:54:44+02:00
List-Id: <comp.lang.ada>

On 4/4/20 1:45 AM, Stephen Leake wrote:
> 
> with Ada.Strings.Unbounded; use Ada.Strings.Unbounded;
> 
> declare
>     Foo : Unbounded_String; -- empty
> begin
>     Foo := To_Unbounded ("hi"); -- allocated on the heap
>     Foo := Foo & To_Unbounded ("bye"); -- allocation grows

Foo := Foo & "bye";

Those should be To_Unbounded_String;

For an issue related to the OP's idea, consider

with System;

procedure Boom is
    type Very_Large_Item is ...;
    type Very_Large_Index is mod System.Max_Binary_Modulus;
    type Very_Large_List is array (Very_Large_Index range <>) of Very_Large_Item;

    Last : constant := ...;

    List : Very_Large_List (0 .. Last);
begin -- Boom
    ... -- Do some thing useful with List
end Boom;

There exists a value N > 0 such that Last = N works and Last = N + 1 results in 
Storage_Error. The actual value of N may vary depending on the compiler, target, 
and the actual machine on which the program is executed.

If you want to handle a List with Last > N, you have to make it an access to 
Very_Large_List unless you care where it is allocated. There is still a value M 
which will result in Storage_Error, but on most machines where you'd try to 
process such a large object, M >> N because on such machines the heap is much 
larger than the stack. Implicit dereferencing makes this change less painful 
than it would be without implicit dereferencing, but there are still usually 
places where explicit dereferencing will be needed, so there is still some pain 
involved even though you don't care where the object is allocated.

It would be nice if there were a compiler option where objects that don't fit on 
the stack would be automatically allocated on the heap, and automatically 
deallocated when they go out of scope.

Similar arguments can be made for a compiler option where all numeric types 
would be accepted, with some implemented in terms of the compiler's ability to 
calculate static expressions exactly, rather than the user having to switch from 
a numeric type to an unbounded-number pkg. This has the added value that such 
pkgs usually lose the automated checks that numeric types have.

All of these issues have been around for some time, and the ARG is aware of them 
and has chosen to take no action. That seems unlikely to change.

-- 
Jeff Carter
"I'm a vicious jungle beast!"
Play It Again, Sam
131