Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)

[Brotsky.pa@Xerox.COM]

KMP writes:

    The presence of an operator like GET-PROPERTIES in the
    language acknowledges the fact that property list as we have
    come to use it is not just an abstract table as some would
    have it be, but in fact an ordered entry capable of doing a
    restartable multiple lookup...

I agree completely.

    ... In my view, this invites (almost begs) the user to
    exploit shadowing or prioritizing...

I agree completely.

    ... If (SETF GETF) is permitted to alter an existing
    ordering, I believe that many programs which use
    GET-PROPERTIES will be  gratuitously broken.

Perhaps (even probably) true.  But this is only remotely connected with
the two points KMP makes which I agree with.  Once you get your hands on
a property list, you can certainly exploit your knowledge that it's an
ordered entry to use shadowing and prioritizing IF you know how that
list is going to be searched and updated by your search and update
functions.  Now we all seem to agree that GETF searches property lists
front to back, so there's no problem with GETF per se.  The problem is
in (SETF GETF) and REMF, about which CLtL simply does not say anything
like "(SETF GETF) and REMF are guaranteed to leave the order of the
pairs in a property list intact" and certainly nothing like "(SETF GETF)
and REMF are guaranteed to leave the particular conses used in a
property list intact (except possibly for removal in the case of REMF)."

I take the thrust of KMP's last remark to be that in fact there are LOTS
of programs out there that rely on one or both of these invariants which
will break if we allow implementations not to respect them.  But then
let's be honest about why we would adopt MAKE-EXPLICITLY-DEFINED in this
case: we would adopt it so some existing code will be made portable ex
post facto.  Exactly how much of this existing code will be made
portable will depend on exactly which invariants we adopt and how much
code assumes exactly those invariants.  KMP seems to have a strong
feeling as to which invariants are being assumed; I would certainly
appreciate his (and anyone else's, for that matter) ballpark estimate of
how much code gets made portable by which invariants.

Frankly, I don't really have a problem with adopting a more precise
semantics for (SETF GETF) and REMF; after all, I think KMP's point about
encouraging shadowing etc. is well taken and the language should specify
*some* well-defined relationship between the plist updaters and
searchers which addresses ordering explicitly.  So I'm willing to adopt
some version of MAKE-EXPLICITLY-DEFINED for (SETF GETF) and REMF, but I
sure would like to see more explicit discussion about balancing the
needs of making old code portable and not handcuffing implementors.
After all, if some existing program has a very exact---but restrictive
to implementors in general----semantics in mind for (SETF GETF) and
REMF, I don't see why that program couldn't implement it in very few
lines.  I hate conditionalizing my code as much as the next person, and
I am constantly writing code that needs to run in more than one
implementation, but it's not clear to me that---especially in the case
of something as localized as (SETF GETF) and REMF---the particular
semantics of particular programs should be adopted by this community as
dictating what implementations must do.

     dan