brady@swift.cs.tcd.ie (04/05/91)
Here is a question about garbage collection. It's easy enough to understand how heap & stack components can be garbage collected - anything that can't be reached by a marking process from the current context is garbage. Likewise, it's easy to figure out what retracted code can't be accessed, and so it removable. However, when it comes to names or functors, what do you implementers do? Do you (a) not bother gc-ing the names store? (b) remove all names that are not accessible from the current program? (c) something else... The problem with (a) is that the name space might just get too big. With (b), it seems that the operation of the standard bip 'current_functor' may be affected - it will mean 'a functor that is referred to by the current program or process' rather than 'a functor that was once defined'. (c), well the problem here is that I can't think of an alternative. Any suggestions? Mike Brady brady@cs.tcd.ie
sfk@otter.hpl.hp.com (Steve Knight) (04/10/91)
This is an interesting question. The Poplog Prolog system, which is the one I normally use, collects all inaccessible atoms. Atoms are accessible either from the "dictionary" or from the currently executing context (or because they reside in the constant portion of the process.) The "dictionary" is a mapping from functor/arity -> location. This mapping is not garbage-collectable, since that would be an error in an incrementally compiled system, but names can be "cancelled". This gives the user the ability to deliver their application without the predicate names being present. However, this feature is only used by confident & competent programmers since some predicates, such as call, require parts of the dictionary to be present. Consequently, the Poplog Prolog module system allows you to cancel the dictionary on a structured and controlled basis. Steve
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (04/12/91)
In article <1991Apr5.143158.7857@swift.cs.tcd.ie>, brady@swift.cs.tcd.ie writes: > Here is a question about garbage collection. > However, when it comes to names or functors, what do you implementers do? I can't speak for any implementors. I will say, however, that if one of the less well-considered proposals currently before the ISO committee is adopted (---- -----, you should know who you are) garbage collecting atoms will be absolutely indispensible on small machines. > Do you (a) not bother gc-ing the names store? > (b) remove all names that are not accessible from the current program? > (c) something else... > With (b), it seems that the operation of the standard bip 'current_functor' > may be affected - it will mean 'a functor that is referred to by the current > program or process' rather than 'a functor that was once defined'. DEC-10 Prolog and C Prolog implemented current_functor/2, but many other Prologs since (including Quintus Prolog) have simply provided a stub that says "this isn't implemented yet". I think it has been agreed for a long time that this EP should not be in the standard. It is rather hard to say what it means, and it is _extremely_ expensive to implement in the WAM or in something like PopLog. current_atom/1 is not in the standard either. If we define current_atom(X) is true when X is a symbol which was reachable from the state of the program at the time the call to current_atom/1 started, and may be true of additional symbols then we have something which can be made to work consistently even in the presence of garbage collection. (The simplest approach involves using a global 'clock' for clause time-stamping.) Making this rigorous may be more trouble than it is worth. The big question is "how much can we promise?". A definition which promises enough to be useful without promising too much to be implementable is current_atom(X) is true only of symbols; the symbols it is true of include the symbols which appear in clauses of static predicates, and may include others. Note that in a "distributed" system like the Logix implementation of FCP, current_atom/1 itself would be extremely difficult to implement, and it's not clear that any useful meaning could be attached to it. -- It is indeed manifest that dead men are formed from living ones; but it does not follow from that, that living men are formed from dead ones. -- Tertullian, on reincarnation.
roland@sics.se (Roland Karlsson) (04/16/91)
The current_atom/1 and current_functor/2 assumes that you somewhere have stored a set of atoms or functors. What set???? In practice those two predicates are meaningless and should not be implemented. Tables for atoms, numbers, functors, predicates, etc have to be garbage collected in any system that claim to be a commercial product. All data areas (tables and stack) shall also shrink on garbage collection. -- Roland Karlsson SICS, PO Box 1263, S-164 28 KISTA, SWEDEN Internet: roland@sics.se Tel: +46 8 752 15 40 Ttx: 812 61 54 SICS S Fax: +46 8 751 72 30
brady@swift.cs.tcd.ie (04/17/91)
In article <1991Apr16.124755.868@sics.se>, roland@sics.se (Roland Karlsson) writes: > > The current_atom/1 and current_functor/2 assumes that you somewhere > have stored a set of atoms or functors. What set???? In practice > those two predicates are meaningless and should not be implemented. > This and previous messages are interesting. Does _anyone_ use current_atom or current_functor for anything? Mike brady@cs.tcd.ie
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (04/23/91)
In article <1991Apr17.105714.7876@swift.cs.tcd.ie>, brady@swift.cs.tcd.ie writes: > In article <1991Apr16.124755.868@sics.se>, roland@sics.se (Roland Karlsson) writes: > > The current_atom/1 and current_functor/2 assumes that you somewhere > > have stored a set of atoms or functors. What set???? In practice > > those two predicates are meaningless and should not be implemented. > This and previous messages are interesting. Does _anyone_ use > current_atom or current_functor for anything? The DEC-10 Prolog library includes a kit of things related to Lisp's "apropos". Amongst other things, there was no current_key/2 in DEC-10 Prolog, so current_key(Symbol, Skeleton) :- current_functor(Symbol, Skeleton), has_at_least_one_record(Skeleton). has_at_least_one_record(Skeleton) :- recorded(Skeleton, _Term, _Ref), !. Basically, current_{atom,functor,predicate} were useful for building program environment tools with. As long as they include the relevant things, which usually means "things in the data base", that's enough. current_functor/2 is dispensible (if you have current_key/2), but current_atom/1 has no substitute that I am aware of. -- Bad things happen periodically, and they're going to happen to somebody. Why not you? -- John Allen Paulos.