[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Plists and NIL.
Date: Thu, 9 Jul 87 09:16:07 EDT
From: dml@nadc.arpa (D. Loewenstern)
1) NIL is a symbol. Like all symbols, it has a plist
(see CLtL p.4 for an example).
Correct.
2) NIL is a list.
Correct.
Therefore, does (SETQ z NIL)
(SETF (GETF z :a) :b)
z
return NIL or (:a :b)?
If you're having to ask this question, you must be confusing GET and GETF.
GETF operates on the plist-format list which is returned by the place named
in its first argument position. In the case you've described where Z
contains the empty list,
(SETF (GETF z :a) :b)
is equivalent to
(SETQ z (LIST* :a :b z))
CLtL is unambiguous on that Z should contain (:A :B) after the series
of operations you're asking about.
(That is, does the property go on NIL's plist or directly into the list
referenced by z?)
Quoting from p166 in the first line of the description of GETF:
``... searches the property list store in <place> ..."
The description of generalized variables on pp93-94 is adequate to allow you
to interpret this, but just to be clear: A place is a form which if evaluated
would access a location. Something is in a place if it would be yield by
evaluating that place. the result of evaluating Z is NIL. Z is the place,
NIL is the something that is in the place Z. The thing which is searched is
the NIL. Updating a place means causing future accesses to that place, Z, to
yield an updated value. SETF does such updating. The thing which is updated
in the case of (SETF (GETF z ...) ...) is Z since Z is the thing whose contents
are searched by GETF.
Golden Common LISP (ver. 2.2LM) resolves this by having no plist on NIL.
I consider this a bug, however.
David Loewenstern <dml@nadc>
It may be that GCLISP doesn't have a plist of NIL. My guess without doing the
requisite research is that this is a bug, but you should take it up with them,
not with the whole Common-Lisp community.
In any case, the question of whether or not NIL has a plist has no
bearing on the question of what GETF does, except in the special case
which you did not mention where (GETF (SYMBOL-PLIST sym) ...) is done.
(The description of GET is quite clear on this at the top of p165 where
it actually makes this equivalence.) Even here, there is no ambiguity
because here it is clear that you search the SYMBOL-PLIST cell:
(GETF Z 'indicator) looks in the value Z. (SETF (GETF Z 'indicator) 'value)
sets the value of Z an appropriate value so that subsequent calls to
(GETF Z 'indicator) will yield the VALUE.
(GET 'Z 'indicator) or (GETF (SYMBOL-PLIST 'Z) 'indicator) looks in the
symbol-plist of the symbol Z. (SETF (GET 'Z 'indicator) 'value) or
(SETF (GETF (SYMBOL-PLIST 'Z) 'indicator) 'value) sets the symbol-plist
of the symbol Z to an appropriate value so that subsequent calls to
(GET 'Z 'indicator) or (GETF (SYMBOL-PLIST 'Z) 'indicator) will yield
VALUE.
By the way, the telltale quotes all through the second paragraph should
be the give-away that Z is being manipulated as a symbol, not a variable.
As a symbol, accesses to it as a slot are typically the standard mode of
interaction. As a variable, references to its value are typically the
standard mode of interaction.
In my opinion, it is appropriate to bring to the attention of this
community situations in which two different vendors make the claim that
there is a unique interpretation to a passage of CLtL and where those
interpretations are not in agreement. I do not believe this is such a case.
I think that all implementors are in agreement and I think you need to do
your homework better. I'm sure your Gold Hill service representative would
have been happy to provide you with this information if you'd gone to
him/her before coming to us.