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: Wed, 29 Jul 2020 15:33:33 -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: Wed, 29 Jul 2020 15:33:33 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="718ff1a9fbd6ef90c6de9fe6b6ffa59f"; logging-data="12256"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19kyFf6cECtnr5kBbAU1wF1IRnsNyhPpTo=" User-Agent: Pan/0.145 (Duplicitous mercenary valetism; d7e168a git.gnome.org/pan2) Cancel-Lock: sha1:jQLe/XX3D1J1uSfdKajPKjb/4hQ= Xref: reader01.eternal-september.org comp.lang.ada:59589 List-Id: On Tue, 28 Jul 2020 16:59:09 +0200, Dmitry A. Kazakov wrote: > On 28/07/2020 16:28, Brian Drummond wrote: >> On Mon, 27 Jul 2020 22:02:57 +0200, Dmitry A. Kazakov wrote: >> >>> On 27/07/2020 19:48, Brian Drummond wrote: >>> >>>> 2) can be implemented internally using pointers, but externally >>>> appears to be a data object, just like Unbounded_String does, with >>>> similar semantics. >>> >>> No, the point is that Unbounded_String is exactly opposite to what is >>> required. In no case it should appear as an object of a different >>> type! >>> >>> Compare access to string P with unbounded string U: >>> >>> for I in P'Range loop -- This is OK >>> P(J) := 'a' -- This is OK >>> >>> Now would you do: >>> >>> To_String (U) (J) := 'a' -- Garbage! >> >> That wasn't the aspect of Unbounded I was getting at. I agree ... >> garbage. >> >> What I meant was that Unbounded doesn't load New, dereferencing, >> deallocation etc onto the programmer, but hides the access details, and >> our indefinite type should do the same (the compiler can probably to a >> better job than the programmer anyway). >> >> I'm suggesting something more like the C++ reference, signalling >> (perhaps by adding a reserved word "indefinite") that fixed size >> allocation won't work; > > Equivalent of C++ reference in Ada is renaming. OK. Not quite sure how complete the correspondence between reference and renaming is, but I can see similarities. >> Q : indefinite String := "hello"; > > I think the keyword is misleading. Maybe this: > > Q : new String := "hello"; Not sure I like. The reader has to make the mental jump from seeing "new" to thinking of this as an indefinite type. There may be a better keyword, open to suggestions, but let's stick to indefinite for now. > And I don't like initialization. Initialisation is unnecessary for indefinite String. It was only used in that example for similarity with previous strings A,P. >> begin >> for I in P'Range loop -- This is OK >> P(J) := 'a'; -- This is OK Q(J) := 'a'; -- also OK. But index >> out of range would raise >> Constraint Error ... >> Q := "hello_world"; -- deallocates, allocates with new bounds >> ... >> end; -- deallocate Q here. > > The rule could be "same pool" as of the container. In the case of a > block, the pool is the stack. In the case of a record member, the pool > is the pool of where the record itself is allocated. So that you could > allocate all object in the same pool. Looks like a good rule. Saves the compiler having to plant deallocations if the whole pool is to be de-allocated. >> It follows that "indefinite" cannot also be "aliased" unless we want to >> implement smart pointers. For simplicity I'd suggest disallowing >> "aliased indefinite" on the grounds that "access" can (should) be used >> instead. > > It makes sense, but there are use cases for having it aliased: > > X : indefinite T; X : aliased indefinite T; > Y : indefinite S (X'Access); -- Access discriminant As elsewhere, "aliased" indicates both to compiler and reader, that the rules are about to get more complicated. Specifically, if X is re- allocated thanks to a different size assignment, all Y must be updated. >> 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). But of course my mind isn't wrapped round all the corner cases, and if you are uncomfortable, I'm probably missing a very good reason. >> Indefinite can also be applied to records (discriminated, class wide, >> etc) >> here the size is indeterminate and may vary on reassignment. Assignment >> would always be shallow copy (where the record contained access types). > > That would be inconsistent. IMO, it should be a deep copy, provided such > a component would not make the type limited, of which I am not sure. 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. Thank you for your thoughts. I don't know if this is worth developing into an AI. -- Brian