[HARLEQUIN][Common Lisp HyperSpec (TM)] [Previous][Up][Next]


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.


[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996, The Harlequin Group Limited. All Rights Reserved.