Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cwjcc!gatech!hubcap!billwolf%hazel.cs.clemson.edu From: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) Newsgroups: comp.sw.components Subject: Re: Re: Garbage Collection & ADTs Message-ID: <6563@hubcap.clemson.edu> Date: 24 Sep 89 17:51:07 GMT References: <909@scaup.cl.cam.ac.uk> Sender: news@hubcap.clemson.edu Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu Lines: 74 From scc@cl.cam.ac.uk (Stephen Crawley): >> [Bill then describes a scheme where the application catches a >> STORAGE_ERROR exception, causes the current transaction to be >> aborted and throws away some (global) data structures after >> asking the user.] > > This is unrealistic. It assumes that there are enough large global > data structures to be thrown. It also assumes that the application > contains the necessary code for interacting with the end user; i.e. > asking questions that he/she has a chance of understanding. Neither > will be true in general. This hasn't even a remote resemblance to what I said. The ADT aborts the transaction because it can't satisfy the request. The user receives an exception to that effect. The user does something to alleviate the problem (e.g., selecting and destroying a data structure) in the process of handling the exception, and proceeds to retry the operation. Incidentally, the questions you are asking (and this is NOT, repeat NOT, intended to reflect negatively on Mr. Crawley) in this and at least one previous article indicate that you do not really understand generics or exception handling at all, and I would therefore suggest that you investigate some basic Ada texts in order to understand these basic concepts and better participate in the discussion. > I define junk to mean dynamically allocated space which was allocated > in the current scope (or passed down from a higher scope) that is no > longer accessible from an in-scope variable anywhere in the program. > In a complex program, such junk may be generated in such a way that > it IMPOSSIBLE for any application code or any library ADT to keep track > of its accessibility ... without implementing a garbage collector! And I contend that if the program is that complex, then it is badly written; the programmer probably has not made use of the basic principle that "abstraction is the fundamental means by which the computer scientist can combat complexity". Abstract data types are an integral part of this process. >> then we require a "Read Programmer's Mind" instruction. > > Oh no we don't!!!! A garbage collector can (and will) reclaim a lot of > this junk by tracing all in-scope variables etc. The garbage collector > can do a "perfect" job of this. Storage reclamation code in an ADT or > the application can only do a half-hearted job in difficult cases. > Such a difficult case might involve detecting that a subgraph containing > cycles has become detached from its root ... the case where reference > counting does not work. My argument is that the difference between a > perfect job and imperfect job may be enough to cause the program to die. Not a difficult case at all, if we have (for example) a generic Simple_Directed_Graph ADT. Again, the argument here reflects a lack of understanding of the basic ideas behind generic software components. >> The rule is simple: Leave the use of pointers to ADT implementors, >> and simply reuse the code they produce. Exploit to the absolute >> fullest the hard guarantees (proper space management, serializability, >> recoverability, concurrent processing, etc.) that the ADT implementors >> worked so hard to provide you with, and thy Manager will be pleased. > > Except that ADT implementors haven't because it is impossible. It is quite possible; start by reading Booch's "Software Components with Ada", and once you understand that you will be in a position to consider some more advanced techniques. Then if you still want to argue against my position, you will at least understand it well enough to launch a reasonable attack. Bill Wolfe, wtwolfe@hubcap.clemson.edu