ALIST-NILNIL is permitted to be an element of an a-list but very little of use can be done with such an element, and the idea can be confusing.
In most situations where an a-list entry is to be removed, it is done by straightfoward uses like (SETQ THE-ALIST (REMOVE THE-ENTRY THE-ALIST)) or (SETQ THE-ALIST (DELETE THE-ENTRY THE-ALIST)).
Relatively few situations require the more advanced technique of (SETF (CAR THE-ALIST-TAIL) NIL) in order to remove an entry from a list. Usually these situations involve multiple pointers into different parts of the same a-list, or very long a-lists where DELETE or REMOVE would take a long time.
Proposal ALIST-NIL:DISALLOW:
Change the definition of an a-list to require all elements to be real conses. Uses of ASSOC with non-standard a-list would be an error.
ASSOC 'X '(NIL (X . 3))) is currently defined to return (X . 3). Under this proposal, this would be an error.NIL in an a-list complicates the description considerably.
This change would make the relationship between FIND (with key of #'CAR) and ASSOC simpler and easier to explain.
NIL in an a-list.
#1: A user wants a leading NIL on an a-list so that if the list is empty, there's still be a tail to which cells could be attached in the future. That is, (DEFVAR *MY-ALIST* (CONS NIL '())) so that ...(NCONC *MY-ALIST* (LIST new-cell))... would always be possible as a side-effect and ...(ASSOC element *MY-ALIST*)... would always be possible for lookup. It might be argued that this is more clearly written: (DEFVAR *MY-TABLE* (CONS NIL '())) (DEFUN ADD-ENTRY (ENTRY TABLE) (NCONC TABLE (LIST ENTRY))) (DEFMACRO MY-TABLE-CONTENTS (X) `(CDR ,X)) ...(ADD-ENTRY new-cell *MY-TABLE*)... ...(ASSOC element (MY-TABLE-CONTENTS *MY-TABLE*))...
#2: A user might want to splice out an element from an a-list, preserving the place that the element occupied in the list. In the very rare cases where this was necessary, one could rewrite: (DEFUN VOID-FIRST-ENTRY (ALIST) (SETF (CAR ALIST) NIL)) as: (DEFUN VOID-FIRST-ENTRY (ALIST) (LET ((ENTRY (CONS NIL NIL))) (SETF (CAR ENTRY) (GENSYM)) ;or ENTRY or something otherwise unique (SETF (CAR ALIST) ENTRY))) This might change the behavior of ASSOC-IF, ASSOC-IF-NOT, RASSOC-IF and RASSOC-IF-NOT depending on the predicate used. Also, in this case, the user must also consider that whatever is used as the unique key must be acceptable to ASSOC.
In rare cases where neither of these rewrites were acceptable, the user could still write his own variant of ASSOC to handle NIL even if the system version did not.
FIND (with a :KEY of #'CAR) and ASSOC (with no key) would be identical.Some people consider this change gratuitous.
The cleanup committee discussed some interesting optimizations of ASSOC where the existing situation (special-casing NIL) didn't actually cost in performance (at least in the special case where the predicate was EQ or EQL), so performance issues were dismisse d as a rationale for this change.
9+(DEFAULTFONT 1 (GACHA 12) NIL (TERMINAL 8))//zº*start* 01188 00024 USa Return-Path: <CL-Cleanup-mailer@SAIL.Stanford.EDU> Redistributed: xerox-cl-cleanup^.pa Received: from SAIL.Stanford.EDU ([36.86.0.194]) by Xerox.COM ; 13 OCT 88 12:37:23 PDT Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88 12:37:44 PDT Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 475700; Thu 13-Oct-88 15:36:11 EDT Date: Thu, 13 Oct 88 15:35 EDT From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: ALIST-NIL (Version 4) To: CL-Cleanup@Sail.Stanford.EDU cc: JonL@Lucid.COM, Moon@STONY-BROOK.SCRC.Symbolics.COM Message-ID: <881013153546.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes from the Fairfax meeting...
Cleanup meeting:
KMP: Moon has weak opposition to this proposal, primarily on compatibility grounds.
Otherwise, we felt this was ready to vote.
X3J13 meeting:
JonL: Worried that Lucid would have to change. [KMP pointed out that this isn't true because it becomes an "is an error" situation. JonL said that might be ok, but wanted to think more about it.]
The issue was not voted upon.