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!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: How to get Ada to ?cross the chasm?? Date: Thu, 3 May 2018 17:27:23 -0500 Organization: JSA Research & Innovation Message-ID: References: <1c73f159-eae4-4ae7-a348-03964b007197@googlegroups.com> <87k1su7nag.fsf@nightsong.com> <87po2la2qt.fsf@nightsong.com><87in8buttb.fsf@jacob-sparre.dk> <87wowqpowu.fsf@nightsong.com><16406268-83df-4564-8855-9bd0fe9caac0@googlegroups.com><87o9i2pkcr.fsf@nightsong.com> <87in88m43h.fsf@nightsong.com><87efiuope8.fsf@nightsong.com><322f9b26-01de-4753-bb50-6ef2f3d993d8@googlegroups.com><87a7th9pd1.fsf@nightsong.com> <87h8no1nli.fsf@nightsong.com> Injection-Date: Thu, 3 May 2018 22:27:25 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="17570"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader02.eternal-september.org comp.lang.ada:51954 Date: 2018-05-03T17:27:23-05:00 List-Id: "Paul Rubin" wrote in message news:87h8no1nli.fsf@nightsong.com... ... > What the function is really generating is a tree structure, with nodes > that can be expanded into further nodes or to sentences. So you should > really represent those sentences as trees, where you print a sentence by > traversing the tree recursively. Surely, and you can use the tree container to represent such a tree. No GC, no explicit memory management, no fuss, no muss. And similarly in the original code, presuming that it is fast enough. The compiler does any needed memory managment. The cost of doing that is rarely an issue (see the many threads here on premature optimization). ... > There are various ways you can deal with this storage management issue. > So you can think up a workable approach, implement and debug it, write > regression tests and monitoring for it, etc. Or you can just not think > about it at all, allocate new data whenever you want, and let GC take > care of freeing it. Or you can just use the built-in facilities of Ada to do the storage management and not think about it. The original code above did that and somehow you managed to decide that it wasn't good enough unless it had to use GC somehow. > I vote for GC :). Desire for GC is a good way to tell people who want to build quality software from those who just want to throw software at the wall. :-) In any event, why are you here? There is no realistic chance that Ada will ever be changed enough to make it amenable to GC. I proposed such changes multiple times in the past and got nowhere with them. (The problem being that the location of finalization of most objects is too late for any useful GC to be possible -- it's generally associated with the access type, which is usually declared at the library level. Thus GC can't clean up most objects until the type goes away -- which is usually when the program exits.) The compatibility issues have only gotten worse in the mean time -- we've tied down the finalization rules more in the intervening years, so there is likely to be more code that depends upon them. Randy.