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: Tue, 06 Feb 2007 12:07:25 +0100 Message-ID: <06abzrtuhe.fsf@hod.lan.m-e-leypold.de> User-Agent: Some cool user agent (SCUG) Cancel-Lock: sha1:Sx6tOE6e3m9YHbFnBmTloe06ngw= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 88.72.224.62 X-Trace: news.arcor-ip.de 1170759740 88.72.224.62 (6 Feb 2007 12:02:20 +0200) X-Complaints-To: abuse@arcor-ip.de Path: g2news2.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!newsfeed.freenet.de!news.unit0.net!newsfeed.arcor-ip.de!news.arcor-ip.de!not-for-mail Xref: g2news2.google.com comp.lang.ada:9020 Date: 2007-02-06T12:07:25+01:00 List-Id: Ray Blaak writes: > Markus E Leypold writes: >> 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. > > Does that automatically preclude any access types, unbounded strings, etc., > then? That would be quite a limited language. Not necessarily. It precludes any _handling_ of stuff in a way that doesn't allow the compiler to de-allocate memory when leaving the scope. Basically the compiler would look at what happens and instead of using heap allocated (GC'ed) memory it would use 'Controlled' memory (in Ada parlance). And BTW: AFAIK that has already been done once for some obscure subset of ML. > > That would simplify GC right off the bat. Maybe it wouldn't be needed at all, > right there. :-). >> 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. > > My reaction is to not trust testing only to gain the measure of confidence > needed. You must be able to prove the the equivalence well enough. Right. Therefore (in the case where more trust is needed) the proof of euivalence by equivalence transformations (for a suitable definition of equivalence). > Also, if the non-GC version was realtime, why wouldn't the first one be? Because the interfaces change. Only the data processing provided is equivalent, but the way data is passed and retrieved, changes. > Where is the difference in behaviour? If you have no heap, then > wouldn't execution should be equivalently predictable in either > case? I'll try to make up a simple, but not necessarily good example. This is not about runtime GC but about going from GC to manual memory management, but I hope it will serve. The programs concatenate 2 strings: With GC (naive implementation) let concat1 (s1:string) (s1:string) = s1 ^ s2;; With manual MM. let concat2 (s1:string) (s2:string) (result: string ref) = result := Some (s1 ^ s2) I realize this might not be the beste example, since I just made it up. But the idea is, that (string ref) is (by the compiler) translated into a char* and that result := ... actually becomes a malloc() plus a copying of memory. some_var := None would compile to explicit deallocation (pointer is overwritten with null). Both functions are equivalent (they concatenate strings), but the second would not be required to work in a GC'ed environment. Similarily, I think, it might be possible to avoid malloc() if everything is done in static or local buffers. Regards -- Markus