From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Path: eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Brian Drummond Newsgroups: comp.lang.ada Subject: Re: Proposal: Auto-allocation of Indefinite Objects Date: Thu, 30 Jul 2020 17:04:52 -0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <94a54092-a56f-4a99-aaec-08dd611c8fd8@googlegroups.com> <8a502b6c-4609-4cd8-b292-5797fe6421e1n@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Thu, 30 Jul 2020 17:04:52 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="4b6777b279044f9fbd7f3bfb777c58a1"; logging-data="17954"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+cr3NzWBSevATK8Dm9X5kfqeQy6kBF/kc=" User-Agent: Pan/0.145 (Duplicitous mercenary valetism; d7e168a git.gnome.org/pan2) Cancel-Lock: sha1:FlGq5V3B0SlouzCuqaUhkedRLK4= Xref: reader01.eternal-september.org comp.lang.ada:59602 List-Id: 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. If it cannot prove, it should assume not. In which case allocation is NOT on stack or heap so organised, and it knows before generating code that heap allocation and possible relocation is required. In this latter case the situation is no worse than if the programmers explicitly used an access type and handled the allocations and relocations and frees themselves, but without requiring that level of detail. > 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? >> 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? Thanks, this one I'll have to think about. -- Brian