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=0.7 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!uw-beaver!uw-june!klaiber From: klaiber@june.cs.washington.edu (Alexander Klaiber) Newsgroups: comp.lang.ada Subject: Re: Garbage Collection Message-ID: <6702@june.cs.washington.edu> Date: 13 Dec 88 01:02:14 GMT References: <65475@ti-csl.CSNET> <3848@hubcap.UUCP> Reply-To: klaiber@uw-june.UUCP (Alexander Klaiber) Organization: U of Washington, Computer Science, Seattle List-Id: In article <3848@hubcap.UUCP> wtwolfe@hubcap.clemson.edu writes: >>From article <65475@ti-csl.CSNET>, by gateley@m2.csc.ti.com (John Gateley): >> This method is fine, as long as no structures are shared. [...] >> [...] if your programming style never uses shared structure, then you >> don't need GC. > Precisely. > Structural sharing is nothing more than a euphemism for hacking. > It is the spatial equivalent of what hackers enjoy doing with time > in the name of efficiency, in their unmitigated zeal to violate every > form of abstraction, to throw all traces of readability and reliability > to the winds. Apart from the amount of cheap flames you've thrown in, do you think you REALLY have thought this out? Sure, structure-sharing *is* sometimes used with the goal of conserving memory, but there are cases where it is vital; especially when you're doing object-oriented like programming. Assume I maintain mailing-lists of people and I represent the lists by pointers to objects representing one person each; i.e. type person is (some adt) type mailinglist is new list(person); Now if I have more than one mailing-list, obviously I have structure-sharing: a given person may appear on more than one list. And it is *NOT* very wise to create one copy of each person for every mailing list that person appears on: people can change the addresses and by having just *one* instance of the person around, there is only *one* place where it needs to be changed -- these changes will be completely transparent to the mailing lists or, for that matter, *FOR ANY OTHER REFERENCES TO THE PERSON* that I might later add to the system! In a system such as this, I will need *some* form of keeping track just how many references to a given object (a person) exist, so I know when I can safely deallocate it --- now one method is to have the programmer take care of it, but that might require making the (mailinglist) and (person) know about each other, thus creating additional dependencies and limiting further extensibility. The other method is to supply GC. Now you *can* do without structure sharing by creating "deep copies" of each reference to any given object --- but you will have to live with the "updating problem" which is well-known in databases where multiple copies of objects are kept. The bottom line is that structure-sharing can be a valuable abstraction tool, and one you apparently are not aware of. > If GC were prohibited, it would infuriate all those who enjoy hacking > with space as opposed to time. Good. Let them use C. Ada is the Why do you want to explicitly *prohibit* it? > Folks, space management in Ada is NOT that difficult. Depends on what kinds of applications you are writing. Note that I do not ask that GC be *required* (obviously that would be rather foolish in real-time applications), but it is sure nice to have it, since it can greatly help to reduce the complexity of your programs by eliminating all these storage-management chores and allowing you to concentrate on the real problems. It sure eliminates a *lot* of possibilities for errors and actually makes programs much more reliable and readable. Maybe *you* are throwing readability and reliability in the wind... Alexander Klaiber klaiber@june.cs.washington.edu P.S.: For complex applications as these, I tend to programm in Smalltalk rather than in Ada, so I might be somewhat biased. But I *have* done o-o programming in C++, and believe me, storage management can be *nasty*!