From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-65-14.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.6 Path: eternal-september.org!reader02.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!cleanfeed1-a.proxad.net!nnrp1-2.free.fr!not-for-mail From: Thomas Newsgroups: comp.lang.ada Mail-Copies-To: nobody Subject: Re: Unchecked_Deallocation with tagged types References: <607b56f8$0$3721$426a34cc@news.free.fr> <07863309-4541-4497-8cec-d88179e634bdn@googlegroups.com> <3d6e49b6-f195-4dc2-bf4b-795f18f2da9dn@googlegroups.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit User-Agent: MT-NewsWatcher/3.5.3b3 (Intel Mac OS X) Date: Mon, 18 Apr 2022 03:51:13 +0200 Message-ID: <625cc411$0$18748$426a34cc@news.free.fr> Organization: Guest of ProXad - France NNTP-Posting-Date: 18 Apr 2022 03:51:14 CEST NNTP-Posting-Host: 91.175.52.121 X-Trace: 1650246674 news-4.free.fr 18748 91.175.52.121:14014 X-Complaints-To: abuse@proxad.net Xref: reader02.eternal-september.org comp.lang.ada:63748 List-Id: In article , "Randy Brukardt" wrote: > "Niklas Holsti" wrote in message > news:ie8uagFqaf2U1@mid.individual.net... > > On 2021-04-20 23:32, Jeffrey R. Carter wrote: > >> On 4/20/21 8:53 PM, Randy Brukardt wrote: > >>> > >>> 'Free makes more sense in a new language (an Ada follow-on). > >> > >> Right. I don't think it would be a good idea to add it to Ada. > >> > >> But I think a new language should not have pointers at all. > >> > >> No more radical than not having arrays. > > > > It seems to me that a language without arrays and pointers would be very > > difficult to use in an embedded, real-time, close-to-HW context. So we > > would lose the nice wide-spectrum nature of Ada. i like "the nice wide-spectrum nature of Ada" :-) If I got it right, it is the thickness*, that is, it goes both far in low level and far in high level. * Natacha Porte, https://www.youtube.com/watch?v=b5lRyBRk0d8&t=430s (during 1:10 - sorry, it's only in french) > > It's important that a new language have a way to interface to existing > hardware and software. So there has to be something that maps to C arrays > and pointers (and the equivalent for hardware). But that doesn't necessarily > have to be something that is used outside of interfacing. An Ada example is > Unchecked_Unions -- they exist for interfacing but shouldn't be used > otherwise. i don't know much "exotic things" (for me) like embedded or real-time programming, but i would not take the risk to exclude users who need low level in various cases (not only in interfaces), so i think it would be better to keep a full thickness with the ability to go far in low level at any place it is considered usefull. > A fixed vector type and a raw general access type would do the > trick, but those could be something that are almost never used outside of > interfacing packages. an other point here, is the ability to create new structures that could be considered as "basic" later. for example Ada.Containers.Multiway_Trees seems to be based on Ada.Containers.Doubly_Linked_Lists, and i don't know if it could be needed / usefull to have trees based on Ada.Containers.Vectors, but based on Ada.Containers.Ordered_Maps, certainly! and sometimes using other high level data structures would be enough, but probably sometimes it would be non-optimal, and maybe, in the worst case, it could be impossible (especially in the event that we had not foreseen all the needed high level data structures) so, i think: - we could keep arrays as is, no matter if they are rarly used. - for access types, it would be nice to find a kind of "controlled access type" that allows: - to access the "raw general access type", as low level type, when needed, - to need not Unchecked_Deallocation, making automatic Deallocation, - and which would not be too much high level (for example Ada.Containers.Indefinite_Holders is fine). -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/