REMF and REMPROP

[Dan Hoey <hoey@nrl-aic.ARPA>]

I can't believe that shredding discarded pieces of plists to help
garbage collection could serve much of a useful purpose.  But it might
be very useful in CDR-coded implementations to do REMF by copying the
last pair of the property list into the newly-vacated position, and
even to secretly remember the empty spaces this leaves after the end of
the list for future use by (SETF (GETF...)).  This would mean that
structure once shared with the plist backbone might be changed fairly
surprisingly by REMF or (SETF (GETF...)).

I think users who rely on the assumption that system functions are
implemented in the most obvious way are in too much trouble for a
warning about REMF to help them.  There has to be a distinction made
between ``exploiting loopholes'' in the standard and taking advantage
of the standard's deliberate flexibility.  The implied contract of the
property list functions has to be spelled out, something like:

    GETF does not structure.  (REMF <place> ...) and 
    (SETF (GETF <place> ...)) modify only <place> and its top-level
    list structure.

It's unfortunate we can't get along without the first sentence,
considering what a win it can be to dynamically order property lists.

Dan