Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!icdoc!syma!ianr From: ianr@syma.sussex.ac.uk (Ian Rogers) Newsgroups: comp.object Subject: Re: Stash Collection Keywords: Poplog, "temporary" properties Message-ID: <3994@syma.sussex.ac.uk> Date: 10 Dec 90 17:00:41 GMT References: <2849@esquire.dpw.com> <1990Nov27.074534.17744@Think.COM> Organization: Univ. of Sussex, Brighton, UK Lines: 109 Summary: lou@cs.rutgers.edu (lou) writes: > > there was a recent discussion on > comp.lang.lisp of "weak" links (I think that was the term), which are > links that can be followed to access some storage, but which do not > make the collector think the storage is "in use". Thus, when garbage > collecting, the storage looks like it can be reclaimed. (Of course, > the garbage collector has to notice these weak links and reset them to > NIL if to reclaims the storage they point to.) The Poplog AI programming environment does this with "temporary" properties. I've added, to the end of the message, a (fairly longish) section of one of the online reference files which describes this behaviour. Note that these properties are easily accessable from all four of the Poplog languages: Lisp, ML, Prolog, and Pop11 (just like Lisp but with a much richer and more readable syntax). burley@pogo.ai.mit.edu (Craig Burley) writes: > > ... to handle, without > some changes, an approach I call (for lack of a decent education) the > "explode/implode method". Here, information may be represented in a > compacted or source fashion, such as a list of identifier names > ... > > Then if more space is needed, the exploded form somehow needs to be told > to trash itself, and it should only do that if it either sees that it still > has a weak link to its imploded sibling or if it can recreate its imploded > sibling, after which it replaces any references to itself with references > to its imploded sibling, and trashes itself. "Destroy" properties (also described below) could handle this. ! Properties come in two basic types: permanent and temporary (in ! addition to a special 'destroy' type for associating destroy actions ! with objects, see below). The difference between permanent and temporary ! involves the interaction of the property with garbage collection. ! Suppose a property PROP has an entry associating an item VAL (the value) ! with an item ARG (the argument), and suppose that there are no other ! references remaining to the argument ARG elsewhere in the system (i.e. ! ARG is otherwise garbage). Then, if the entry were treated by garbage ! collection like any other record, the presence of ARG in the entry would ! prevent it (i.e ARG) from being garbaged. Similar remarks apply to the ! value VAL if that too has no other references remaining. ! ! For some applications this may be the desired behaviour; for others, ! the property entry may no longer be required at all if either ARG or VAL ! are otherwise garbage. The system's action in this respect can therefore ! be specified for the entries in a given property, by supplying one of ! the following keyword arguments when the property is initially ! constructed (with -newproperty- or -newanyproperty-): ! ! Keyword Meaning ! ------- ------- ! "perm" Permanent: entries are never discarded. ! ! "tmparg" Temporary on the argument: entries are discarded for ! which the ARG items are otherwise garbage. ! ! "tmpval" Temporary on the value: entries are discarded for ! which the VAL items are otherwise garbage. ! ! "tmpboth" Temporary on both: entries are discarded for which ! either the ARG or VAL items are otherwise garbage. ! ! "tmpclr" Temporary cleared: all entries are cleared from the ! property at every garbage collection. ! ! (Note of course that if an entry is kept in any case, then both ARG and ! VAL items are forced to be retained as well, regardless of whether they ! were garbage or not.) ! ! Thus for example, "perm" properties may be used for retaining ! permanent tables of information, and "tmparg" properties for attaching ! ad hoc pieces of information to arbitrary records (which will be garbage ! collected along with the records). "tmpclr" properties are useful for ! short-term caching of computed data. ! ! A 'destroy' property is a special kind of "tmparg" property. Like ! the latter the presence of ARG as the argument of a destroy property ! entry will not stop it from being considered as garbage, but instead of ! simply discarding ARG, the entry containing it is added to a special ! list maintained by the garbage collector. At the end of the garbage ! collection those destroy entries whose argument would otherwise have ! become garbage (i.e. and the entry discarded) are examined. If their ! value slot contains a procedure, or an identifier whose -idval- is a ! procedure, the procedure is run, with ARG passed as argument. Only then ! is ARG discarded in the same manner as with temporary properties. ! ! Destroy properties thus allow arbitrary procedures to be attached to ! objects in such a way that the procedure gets run, with the object as ! argument, at the point at which the object would otherwise have become ! garbage (the point of its destruction). More information about Poplog can be got from popmanager@uk.ac.susx.cogs ttfn, Ian Rogers Poplog Janet/Arpa: ianr@uk.ac.susx.cogs | Cognitive & Computing Sciences uucp: ukc!cogs!ianr | Sussex University, Falmer, voice: +44-(0)273-606755 x2392 | Brighton, England. "Deep in the fundemental heart of mind and Universe," said Slartibartfast, "there is a reason" - Douglas Adams