Subject: Re: All instances From: Erik Naggum <email@example.com> Date: Sun, 17 Jun 2001 23:21:31 GMT Newsgroups: comp.lang.lisp Message-ID: <firstname.lastname@example.org> * email@example.com > For example, to find a "lost" object. Common Lisp features a garbage collector. If there is no way you can reference an object, it does not matter whether it exists (in memory) or not. Consequently, it saves on memory consumption to (re)use the space used by objects that people have "lost" for something they have not lost. If the system hangs on to objects after you lost them, there is probabl a very good reason for that, and an accompanying mechanism to delete those objects. Otherwise, there is no way you can both lose it and fint it. I wouls guess that only a few kinds of objects satisfy this condition, such as processes, streams, packages, symbols, etc. In fact, all operating system resources _should_ satisfy this condition, but they do not always do so. E.g., streams usually reflect a scarce system resource that you really want to be able to recover and your Common Lisp system should have a way to go from system resource to high-level resource, such as from a file descriptor to a stream. This particular mapping is astonishingly simple to accomplish and it is a shame that it needs to be done manually. > I might have only vague knowledge of a particular object, and might want > to inspect it to learn more about it. It would be handy to be able to > iterate through all objects to find those that match a pattern, which > might represent the vague knowledge I have of the object I'm looking for. Then it would serve your purposes much better to learn how to find objects that might satisfy your needs than to find all objects in order to test them to satisfy your needs. From what you keep telling me about SmallTalk, it seems like a seriously misdesigned language when it lets people rummage around the garbage to find something or other that may or may not have been "lost". However, since I do not consider SmallTalk misdesigned, I instead consider your usage of these features _abusive_. Similar abuse may of course be accomplished in Common Lisp. The garbage collector will necessarily know about all (live) objects, and you may ask it nicely to return a list of all of them -- it necessarily has a way to reference all objects independently of all other references. In Allegro CL, you do that with the function (excl::get-objects <object-type-id>). Evaluate (room t) to see which object types and ids are available. > You might be thinking of small and medium sized projects done by one > person, such that it's easy to keep track of all the details. But I'm > used to working on very large projects, where I have to understand the > work of large numbers of other programmers. Such work is often poorly > documented, and best understood by browsing and inspecting the running > code and objects. I might have no idea where to look among megabytes of > source code for a particular bug, but might be able to find it fast by > browsing and inspecting various objects related to it. This leads me to believe that the existence of the features you want encourage the abuse you have described and apparently consider a plus, while I hold the view that if certain things are harder to do than others, people will do other things to avoid the hardest part of the job. In a nutshell: If it is harder to document than to browse, people will browse, but if it is harder to browse than to document, people will document. Programming languages are all about built-in convenience. In a twisted form, the Sapir-Whorff hypothesis, that languages shape the way we think, applies because of sheer laziness and/or intelligent use of resources (the two frequently coincide). Incidentally, there is the function apropos, and some Common Lisps even feature an apropos-regexp function for those who think regexps are cool. #:Erik -- Travel is a meat thing.