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!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Languages don't matter. A mathematical refutation Date: Thu, 9 Apr 2015 18:35:42 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <87h9t95cly.fsf@jester.gateway.sonic.net><04f0759d-0377-4408-a141-6ad178f055ed@googlegroups.com> <871tk1z62n.fsf@theworld.com><87oan56rpn.fsf@jester.gateway.sonic.net><877fts7fvm.fsf@jester.gateway.sonic.net><87twwv66pk.fsf@jester.gateway.sonic.net><32ecaopodr1g.1xqh7ssdpa2ud.dlg@40tude.net><87pp7j62ta.fsf@jester.gateway.sonic.net><87pp7hb2xo.fsf@jester.gateway.sonic.net><5rxvgyes5xg8.1mqq86gacbsb1.dlg@40tude.net><87lhi5ayuv.fsf@jester.gateway.sonic.net> <87oan0aote.fsf@jester.gateway.sonic.net> <878ue3ff6y.fsf@jester.gateway.sonic.net> NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1428622543 29206 24.196.82.226 (9 Apr 2015 23:35:43 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 9 Apr 2015 23:35:43 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:25501 Date: 2015-04-09T18:35:42-05:00 List-Id: "Georg Bauhaus" wrote in message news:mg5eoh$k18$1@dont-email.me... > On 08.04.15 23:16, Randy Brukardt wrote: >> That's what I call "trained ape" programming. It's so easy, anyone can do >> it, so anyone does, and we get the mounds of crapware out there that >> barely >> works and steals your identity at the same time. Bah-humbug.;-) > > Suppose > > (1) there exists an implementation of Ada that supports automatic > memory management(*), and That's not really possible, unless you're willing to forget controlled objects. (See my previous message for details.) There are some technical reasons that make it rather hard to fix this (we don't want finalization occuring at random places in the program code, because of the possibility that it has tasking or other side-effects -- it would be very difficult to write a correct Finalize routine if that was possible). [My proposal was that "early" finalization would only be allowed at places in the code where finalization would normally happen, scope exit and the like]. > (2) that doing all of the following becomes really easy: > - to specify a pool for objects that are handled automatically, pragma Default_Storage_Pool. See 13.11.3 in Ada 2012. :-) > - to explain what that means, and See 13.11.3 in Ada 2012. :-) > - to pick a pool that exists and is portable (sort of). It would seem easy enough for those to exist, assuming that some mechanism for tracing is invented. (That's the thing that a user can't sensibly write themselves, meaning the implementer and the language would need to be somehow involved. Otherwise, you could just use Grein's Smart Pointers and forget the whole special pool thing.) > Then, I think, these conditions will describe something one might > have come to expect of Ada: it keeps promises (to be GC-able) and > makes everything explicit in source. Sounds good. But how to do tracing without a lot of overhead?? Randy.