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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b307bd75c8071241 X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: newbie Q: storage management Date: 1997/05/03 Message-ID: #1/1 X-Deja-AN: 239106821 References: <5k5hif$7r5@bcrkh13.bnr.ca> <336754A0.41C6@magellan.bgm.link.com> <336A065B.41C6@magellan.bgm.link.com> Organization: New York University Newsgroups: comp.lang.ada Date: 1997-05-03T00:00:00+00:00 List-Id: Samuel Mize said <> Actually this is quite wrong. Samuel, you were not there, and so you are guessing, and you are guessing wrong! In fact the viability of garbage collection in a language at the level of Ada is far from established. We have no good proof by example that it is feasible. Real java compilers, as opposed to safe Java interpretors, may give such proof. One very large item of concern is that if you have a language that provides system level features that let you mess at a low level, it is all too easy to cause damage to critical structures that GC depends on, and bugs caused in this way can be diabolical to track down. I speak from experience here, during my work on SPITBOL, we occasionally ran into such bugs (I have been playing with GC for a long time, see my paper in 1977 Software Practice and Experience, and also Steve Burov's thesis, from 1978, on garbage collection in Algol-68). Algol-68 might have given some demonstration that GC could be widely used, if A68 itself had been widely used. Certainly in England, where A68 was widely used, all sorts of applications ended up successfully using GC. But the fact of the matter is that the great majority of people are unconvinced, and I was certainly not able to convince the Ada 95 committee to evenm consider GC, even in the context of the information systems annex as an optional feature. There was indeed a vocal minority on this issue, but it was a very small minority (1, me) and it was on the other side. The great majority, namely everyone else, was opposed to going beyond the Ada 83 design point, i.e. allowing GC, but not insisting on it. Right now, the best thing, rather than flaming away on CLA, would be for advocates of GC to implement GC in GNAT and desmonstrate that it works fine. (Hint: use the Modula-3 work as a starting point) Certainly no one could have suggested removing the explicit deallocation from Ada 95, that would have been a truly silly suggestion, which would not have been given 2 seconds of attention. What could have been done was to say some warm words about GC, and define the semantics of Storage_Error in the presence of GC a little more precisely, but even that was not acceptable to the great majority.