OK, a colleague ran into trouble porting some existing code to a new
lisp implementation. The problem centered around the use of keyword
symbols to name slots:
(defclass some-class ()
((:slot1 :accessor slot1 :initarg :slot1)))
This class definition works in some lisp implementations (for example
MCL, OpenMCL, CLISP) and not in others (Allegro, Lispworks, SBCL,
CMUCL).
I tried to find something definitive in the HyperSpec which would say
whether the use of keywords was legal here. Unfortunately, the closest
thing that I could locate was the following in the DEFCLASS macro entry:
"slot-name -- a symbol. The slot-name argument is a symbol that is
syntactically valid for use as a variable name"
Now, it seems that the key phrase is "valid for use as a variable name",
which I was having some trouble pinning down. The section on symbols
and their evaluation uses the term "constant variables" to refer to,
among other things, keywords.
But on the other hand, I don't really see what other restriction would
be possible on symbol names other than that they be legally bindable, in
order to justify the restrictive language in the DEFCLASS page.
So my question is:
Does the Specification rule out the use of keywords as slot names?
- Tom.
P.S. The error message from CMUCL complains that since the slot name is
a keyword, it can't be bound. But then again, I don't see where there
is any need to bind the name of the slot to a particular value.
--
Thomas A. Russ, USC/Information Sciences Institute
···@sevak.isi.edu (Thomas A. Russ) writes:
> OK, a colleague ran into trouble porting some existing code to a new
> lisp implementation. The problem centered around the use of keyword
> symbols to name slots:
>
> (defclass some-class ()
> ((:slot1 :accessor slot1 :initarg :slot1)))
>
> This class definition works in some lisp implementations (for example
> MCL, OpenMCL, CLISP) and not in others (Allegro, Lispworks, SBCL,
> CMUCL).
>
> I tried to find something definitive in the HyperSpec which would say
> whether the use of keywords was legal here. Unfortunately, the closest
> thing that I could locate was the following in the DEFCLASS macro entry:
>
> "slot-name -- a symbol. The slot-name argument is a symbol that is
> syntactically valid for use as a variable name"
Well, the symbol C is also syntactically valid for use as a variable.
Too bad, I evaluated (defconstant C 42), and now I cannot _semantically_ do:
(let ((C 43)) (print C)) anymore :-(
> [...]
> So my question is:
>
> Does the Specification rule out the use of keywords as slot names?
I don't think so. It said syntactically, not semantically.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"By filing this bug report you have challenged the honor of my
family. Prepare to die!"
From: Christophe Rhodes
Subject: Re: Does CLOS allow slot names to be keywords?
Date:
Message-ID: <squ0aawwsp.fsf@cam.ac.uk>
···@sevak.isi.edu (Thomas A. Russ) writes:
> So my question is:
>
> Does the Specification rule out the use of keywords as slot names?
I think so. What else could it mean. (Pascal's argument about
semantic validity isn't terribly useful, because by that argument
every symbol is syntactically valid for use as a variable name, so the
sentence would mean nothing.)
> P.S. The error message from CMUCL complains that since the slot name is
> a keyword, it can't be bound. But then again, I don't see where there
> is any need to bind the name of the slot to a particular value.
Well, there's with-slots, and potentially there's machinery internal
to the implementation which does similar things. Not particularly
compelling, I admit.
Christophe
From: Pascal Costanza
Subject: Re: Does CLOS allow slot names to be keywords?
Date:
Message-ID: <474tf3FdtfrcU1@individual.net>
Thomas A. Russ wrote:
> OK, a colleague ran into trouble porting some existing code to a new
> lisp implementation. The problem centered around the use of keyword
> symbols to name slots:
>
> (defclass some-class ()
> ((:slot1 :accessor slot1 :initarg :slot1)))
>
> This class definition works in some lisp implementations (for example
> MCL, OpenMCL, CLISP) and not in others (Allegro, Lispworks, SBCL,
> CMUCL).
>
> I tried to find something definitive in the HyperSpec which would say
> whether the use of keywords was legal here. Unfortunately, the closest
> thing that I could locate was the following in the DEFCLASS macro entry:
>
> "slot-name -- a symbol. The slot-name argument is a symbol that is
> syntactically valid for use as a variable name"
>
> Now, it seems that the key phrase is "valid for use as a variable name",
> which I was having some trouble pinning down. The section on symbols
> and their evaluation uses the term "constant variables" to refer to,
> among other things, keywords.
>
> But on the other hand, I don't really see what other restriction would
> be possible on symbol names other than that they be legally bindable, in
> order to justify the restrictive language in the DEFCLASS page.
>
> So my question is:
>
> Does the Specification rule out the use of keywords as slot names?
I think so. Here are some hints:
- In the CLOS discussion mailing list archives (where the CLOS
specification was discussed in the 80's), I have found two relevant
postings. One by David N. Gray on 15/4/88:
"On page 2-25, third paragraph, the sentence "The slot name argument is
a symbol that can be used as a Common Lisp variable name." is confusing.
It seems to be saying that the name becomes defined such that it can be
accessed just like a variable (as in flavors), but this is only true
through the use of WITH-SLOTS, which is not mentioned here. Probably
what was intended was that the slot name must satisfy the same syntactic
requirements as a variable name, i.e. a symbol which is not a keyword,
nil, or t."
A reply to this by David Moon on 16/5/88:
"2-21 3rd paragraph: Someone complained that "The slot-name argument is
a symbol that can be used as a Common Lisp variable name." was
ambiguous. What we mean is that the symbol is syntactically valid for
use as a variable name, what we don't mean is that referencing a
variable with this name will access the slot. This should be rephrased
if possible."
Finally, there is a paragraph in the HyperSpec for defconstant:
"The consequences are undefined when constant symbols are rebound as
either lexical or dynamic variables. In other words, a reference to a
symbol declared with defconstant always refers to its global value."
It's unfortunate that constants are referred to as "constant variables"
(which is a self-contradictory term, AFAICT). In CLtL2, Section 5.1.2
"Variables", constants are _not_ referred to as variables. The relevant
paragraph in CLtL2 is this:
"Certain global variables are reserved as ``named constants.'' They have
a global value and may not be bound or assigned to. For example, the
symbols t and nil are reserved. One may not assign a value to t or nil,
and one may not bind t or nil. The global value of t is always t, and
the global value of nil is always nil. Constant symbols defined by
defconstant also become reserved and may not be further assigned to or
bound (although they may be redefined, if necessary, by using
defconstant again). Keyword symbols, which are notated with a leading
colon, are reserved and may never be assigned to or bound; a keyword
always evaluates to itself."
So my guess is that the wording "named constants" and "constant symbols"
has been changed to "constant variables" on the move from CLtL2 to ANSI
CL, without updating the related paragraph in the CLOS specification.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
From: Thomas A. Russ
Subject: Re: Does CLOS allow slot names to be keywords?
Date:
Message-ID: <ymifylu6ta7.fsf@sevak.isi.edu>
Pascal,
Thanks for the historic background!
--
Thomas A. Russ, USC/Information Sciences Institute