Issue PLIST-DUPLICATES Writeup

Issue:        PLIST-DUPLICATES

Reference:    X3J13/92-102, dpANS 12.24

                Glossary, p.26-33, initialization argument list

                Glossary, p.26-49

                Section 7.1.1, Initialization Arguments

                Section 3.4.1.4, Specifiers for keyword parameters

              X3J13/92-3107, Kim Barrett comment #7

Category:     CHANGE

Edit History: Version 1, 1/6/93, Kim Barrett

Status:       Proposal ALLOW accepted 8-0, March 1993



Problem Description:


 The definition of \term{property list} states that the keys must all be

 distinct under EQ.  This requirement goes all the way back to CLtL1.

 However, it causes some problems.  It forced the editor to define the term

 \term{property list format} and describe some things in terms of that new

 term rather than describing them as simply being property lists, because

 these things were not required to satisfy the distinct keys requirement.

 Initialization argument lists and keyword argument lists are among the most

 pervasive, with the result that, strictly speaking, GETF and friends cannot

 be used to maniplulate such lists.  Instead, users must either write their

 own functions for manipulation of such lists (with a possible concomitant

 performance loss) or rely on implementors to use the "obvious" implementations

 of these functions and hope for the best.


 GET-PROPERTIES is incorrectly documented as accepting a list in

 \term{property list format}, rather than a \term{property list}.  This is a

 technical change without basis in committee decision.  It then goes on to

 refer to that argument as a \term{property list}.


 The terms \term{property}, \term{property indicator}, and \term{property

 value} should probably all be defined in terms of lists in \term{property

 list format} rather than in terms of \term{property lists}.


 The term \term{initialization argument list} is not defined in terms of

 the term \term{property list format}.


Proposal (PLIST-DUPLICATES:ALLOW):


 1. Remove the unique key requirement for \term{property lists}, by deleting

 the following phrase from its definition in the glossary

    ", and in which all \term{keys} are \term{different} under \funref{eq}"

 and adding the following sentence

    "When there is more than one \term{name} and \term{value} pair with

     the \term{same} under \funref{eq} \term{name} in a \term{property list},

     the first such pair determines the \term{property}."


 2. Remove the term \term{property list format}, instead using the term

 \term{property list} throughout the document.


 3. Specify that REMF and REMPROP only remove the first occurance (the

 \term{property}, as specified by (3) above) when there are multiple occurances

 of the same key.  Similarly, specify that SETF of GETF and SETF of GET update

 only the first occurance.


 4. Change the definition of the term \term{initialization argument list} to

 specify that it is a \term{property list}.  This allows the removal of some

 redundant text from the second paragraph of section 7.1.1.


 5. Change the description of keyword argument processing in section 3.4.1.4 to

 use the terms \term{property list}, \term{property}, \term{property indicator},

 and \term{property value} where appropriate.


Editorial Impact:


 One global query replace, a few changes to one glossary entry, and a small

 amount of rewriting of a couple paragraphs.  In some cases the rewriting

 essentially amounts to deleting a bunch of text and then cleaning up.


Rationale:


 Addresses the problem description.


 Item 1 is the leftmost rule used by initialization and keyword arguments.


Current Practice:


 With the possible exception of REMF/REMPROP, does anybody *not* implement

 exactly this?


Cost to Implementors:


 Probably none.


Cost to Users:


 None.


Performance Impact:


 Users can use built-in operators for parsing such things as keyword argument

 lists, possibly improving performance slightly.


Benefits:


 Gets rid of some ugly terminalogical warts.  Makes the document slightly

 smaller.


Discussion:


 In item 3, alternatively, could make it unspecified whether REMF, REMPROP,

 SETFof GETF and SETF of GET affect all or only the first occurance.  However,

 only affecting the first is more consistent with the new definition of a

 property list and property.  Not deleting all means that in some cases where

 using REMF the idiom (do () ((not (remf plist property)))) is useful.