#

## 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.

Copyright 1996-2001, Xanalys Inc. All rights reserved.