DEFCLASS slot names and symbol macros

This issue is quite interesting.

The function to look at is CHECK-SLOT-NAME-FOR-DEFCLASS, from src/pcl/defclass.lisp. With the workaround, it looks like this:

    (cond ((not (symbolp name))
           (slot-name-illegal "not a symbol"))
          ((keywordp name)
           (slot-name-illegal "a keyword"))
      + ((or (eq name t) (eq name nil))
      + (slot-name-illegal "a constant"))
       - ((constantp name env)
       - (slot-name-illegal "a constant"))

...

The workaround idea is to check only for T and NIL, and allow other constants to be used as slots names. The disadvantage is that there will be a failure within WITH-SLOTS when trying to bind these slot names (they will conflict with the constants names which are also visible there). However, when one does not use WITH-SLOTS, things work well.

There is the possibility for the better fix, where a symbol is checked to have a constant expansion, but it is not declared with DEFCONSTANT. Also, note that symbols which have the expansion set with define-symbol-macro or symbol-macrolet do not conflict with the same slots names within WITH-SLOTS.

The question now is: should we prefer a failure within DEFCLASS or a failure within WITH-SLOTS, when a slot name is also a constant's name? Note that

(defclass foo () (bar))

(defconstant bar 1)

always works fine (with the workaround and without it), but

(defconstant bar 1)

(defclass foo () (bar))

fails without the above workaround. Both of them eventually fail when trying (with-slots (bar) (make-instance 'foo) bar).

Please share your opinions! For some additional info, please see the talk on #sbcl: http://ccl.clozure.com/irc-logs/sbcl/2010-11/sbcl-2010.11.14.txt

Roman Marynchak <email address hidden> writes:

> The workaround idea is to check only for T and NIL, and allow other
> constants to be used as slots names.

I don't like this idea at all. What's special about T and NIL?

> The question now is: should we prefer a failure within DEFCLASS or a
> failure within WITH-SLOTS, when a slot name is also a constant's name?

Within DEFCLASS: prefer reporting undefined code early if possible.

Why is the right answer not to replace
  (constantp name env)
with
  (eq (info :variable :kind name) :constant)
?

Christophe

The approach with (eq (info :variable :kind name) :constant) resolves the issue perfectly, and the above original examples (with symbol-macrolet etc.) work fine, while constants (including user-defined) are reported to be the wrong slots names. The only problem is that I have seen a test failure while testing the patched system:

Invalid exit status: package-locks.impure.lisp.

As for now, I cannot say what is wrong there, this problem needs some additional investigation.

The problem occurs also with symbols that have been declared constant variables, and with keywords:

cl-user> (defclass c () (example))

debugger invoked on a SB-INT:SIMPLE-PROGRAM-ERROR in thread #<THREAD "repl-thread" RUNNING {100A85B1C3}>: In DEFCLASS C, the slot name EXAMPLE is a constant.
; Evaluation aborted on #<sb-int:simple-program-error "~@<In DEFCLASS ~S, the slot name ~S is a constant.~@:>" {1006CD9753}>.
cl-user> (defclass d () (:example))

debugger invoked on a SB-INT:SIMPLE-PROGRAM-ERROR in thread #<THREAD "repl-thread" RUNNING {100A85B1C3}>: In DEFCLASS D, the slot name :EXAMPLE is a keyword.
; Evaluation aborted on #<sb-int:simple-program-error "~@<In DEFCLASS ~S, the slot name ~S is a keyword.~@:>" {10072AC063}>.

All the symbols are syntactically valid for use as a variable name. I can't fathom what this clause was intended to mean.

Including keywords, which are symbols that name automatically defined constant variables.

Also, the only places where slot names are used, are in slot-value where they are not evaluated, and in with-slots where they are not evaluated either, therefore they don't need to be free to be bound.

One can give a free name for the variables in with-slots:

CL-USER> (defclass e () ((:e :initarg :e)))
#<STANDARD-CLASS E>
CL-USER> (with-slots ((e :e)) (make-instance 'e :e 42) e)
42
CL-USER>

so there's no reason to constrain slot names.