[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
REMF and REMPROP
Date: Wed, 4 Feb 1987 11:33 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I guess this is yet another thing that needs to be clarified. Here are
a couple of opinions that may be of use in the meantime:
First, it is in the nature of property lists that they get destructively
modified, and it is a remarkably bad idea to write code of the sort you
describe that shares this top-level list structure. Anyone who writes
code that does this should change the code to something sensible and not
quibble about what is legal.
We agree here.
On the other hand, it seems to me that it violates the (implicit)
contract of a destructive operation like REMPROP to take the excised
piece of list and chop it up into little pieces or to re-use the list
cells that it snipped out. The fact that some built-in operation makes
a destructive change does not necessarily give this operation the right,
or the necessary global perspective, to decide what is garbage and what
is not. Sharing is possible in Common Lisp, and it is the garbage
collector's job to decide what cons cells can safely be recycled.
Destructive operations should do what they are documented to do, and no
more.
If this is the case, then they should be documented to do something.
Consider: I can think of two plausible implementations of REMPROP which
"only do their contract". The first one is the zetalisp version which
requires that the top-level list be spliced in a specific fashion. The
second would be a function which pulled all the elements of the plist
after the removed property pair forward, and set the CDR of the tail
NIL. I will argue that both of these functions "do what they are
documented to do, and no more". However, programs which share property
lists would behave differently in the two hypothetical implementations.
So my question is, if this is allowed, why can't I wreak my own havoc
with the spare conses, which has the same effect?