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=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,21960280f1d61e84 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Newsgroups: comp.lang.ada Subject: Re: in defense of GC References: <1169531612.200010.153120@38g2000cwa.googlegroups.com> <1mahvxskejxe1$.tx7bjdqyo2oj$.dlg@40tude.net> <2tfy9vgph3.fsf@hod.lan.m-e-leypold.de> <1g7m33bys8v4p.6p9cpsh3k031$.dlg@40tude.net> <14hm72xd3b0bq$.axktv523vay8$.dlg@40tude.net> <4zwt33xm4b.fsf@hod.lan.m-e-leypold.de> <1j7neot6h1udi$.14vp2aos6z9l8.dlg@40tude.net> <1pzx3y7d2pide.y744copm0ejb$.dlg@40tude.net> From: Markus E Leypold Organization: N/A Date: Mon, 05 Feb 2007 02:19:33 +0100 Message-ID: User-Agent: Some cool user agent (SCUG) Cancel-Lock: sha1:2V7PmDgyHVoyfFWn73E1wGJv1Z8= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 88.72.198.57 X-Trace: news.arcor-ip.de 1170638071 88.72.198.57 (5 Feb 2007 02:14:31 +0200) X-Complaints-To: abuse@arcor-ip.de Path: g2news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor-ip.de!news.arcor-ip.de!not-for-mail Xref: g2news2.google.com comp.lang.ada:8999 Date: 2007-02-05T02:19:33+01:00 List-Id: Ray Blaak writes: > But to do closures properly, one really does need GC. My words. Or to be truthful: They could have been. :-) BTW, you've been discussing (with ... I don't remember) the possibilty of switching GC off. My idea (even with ML-like languages) was always to define a subset of the language which the compiler can implement with a stack only. One could use this subset to embbed real time capable procedures (as prioritized tasks or as interrupt handlers) in a system with as a whole (user interface) does only provide "soft realtime" (i.e. +/- garbage collection times). This should cover even most cases with hard real time requirements. Suitable subsets again could be compiled to pure C code which works without GC (compile time garbage collections) or without heap. It's the compilers job (maybe with help of the annotations) to discover/prove that the code can be translated like that. Seems to me a more useful approach than explicit pointer management. One advantage of that would be that one could start out with code that requires GC, but is "obviously" correct and then transform in correctness preserving steps it into code that doesn't require GC. Both implementations could be tested against each other, at least as far as their computational function goes, not the real time capabilities that are perhaps only possessed by the 2nd variant. Regards -- Markus