From ... Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed00.sul.t-online.de!t-online.de!newsfeed.esat.net!nslave.kpnqwest.net!nloc.kpnqwest.net!nmaster.kpnqwest.net!nreader2.kpnqwest.net.POSTED!not-for-mail Newsgroups: comp.lang.lisp Subject: Re: software "engineering" (again) (was Possible bug in ACL and Corman Lisp?) References: <3C5801B8.C66E1ECC@eurocom.od.ua> <874rkvftex.fsf_-_@noetbook.telent.net> <3C61E133.D9B2A4F2@nyc.rr.com> Mail-Copies-To: never From: Erik Naggum Message-ID: <3223012846567122@naggum.net> Organization: Naggum Software, Oslo, Norway Lines: 39 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 18 Feb 2002 09:20:43 GMT X-Complaints-To: newsmaster@KPNQwest.no X-Trace: nreader2.kpnqwest.net 1014024043 193.71.199.50 (Mon, 18 Feb 2002 10:20:43 MET) NNTP-Posting-Date: Mon, 18 Feb 2002 10:20:43 MET Xref: archiver1.google.com comp.lang.lisp:26755 * Software Scavenger | But how likely is automatic garbage collection to survive? Surely when | computers can program themselves, they will eventually become | sophisticated enough to use the lowest level machine code, optimizing it | for each function, and won't be bothered by the relatively low mental | overhead of keeping track of what memory needs to be freed when. The problem that garbage collection solves is not freeing memory, but that of keeping track of who owns an objects so the owner can free it when certain that no other users know about it. Object-orientation a la C++ makes OOP stand for "Object Ownership Protocols". In effect, the system owns the object in garbage collected systems unless you go to some lengths to claim ownership yourself, such as by having a foreign function make a copy to assert its ownership in the C++ way. This means that there is no distinction between "owner" and "non-owner", which is such a problem in C++-like languages. (Consequently, there is no problem in having multiple garbage collection schemes in operation at the same time.) If you receive an object from a function that is not guaranteed to create a new one just for you, you have to assume that it may be referenced elsewhere. If you do pass an object to a function that is guaranteed not to keep a reference to it, you have to assume it does. Since this stuff requires compile-time knowledge (promisees), the amount of declarations required to use some other allocation mechanism is probably not worth it in human terms, but if you know you are going to create and release an object in the same (controlling) function, the easiest way to deal with this is "resourcing", which should be available in all quality Common Lisp implementations, and which is a technique to manage your own pool of objects, probably using a weak vector (so free objects do not survive a garbage collection phase) to hold free objects from which you allocate if there is one available and to which you return objects when they would have become garbage. /// -- In a fight against something, the fight has value, victory has none. In a fight for something, the fight is a loss, victory merely relief.