+;;; an internal tag for marking empty slots, which needs to be defined
+;;; as early as possible because it appears in macroexpansions for
+;;; iteration over hash tables
+;;;
+;;; CMU CL 18b used :EMPTY for this purpose, which was somewhat nasty
+;;; since it's easily accessible to the user, so that e.g.
+;;; (DEFVAR *HT* (MAKE-HASH-TABLE))
+;;; (SETF (GETHASH :EMPTY *HT*) :EMPTY)
+;;; (MAPHASH (LAMBDA (K V) (FORMAT T "~&~S ~S~%" K V)))
+;;; gives no output -- oops!
+;;;
+;;; FIXME: It'd probably be good to use the unbound marker for this.
+;;; However, there might be some gotchas involving assumptions by
+;;; e.g. AREF that they're not going to return the unbound marker,
+;;; and there's also the noted-below problem that the C-level code
+;;; contains implicit assumptions about this marker.
+;;;
+;;; KLUDGE: Note that as of version 0.pre7 there's a dependence in the
+;;; gencgc.c code on this value being a symbol. (This is only one of
+;;; several nasty dependencies between that code and this, alas.)
+;;; -- WHN 2001-08-17
+;;;
+;;; FIXME: We end up doing two DEFCONSTANT forms because (1) LispWorks
+;;; needs EVAL-WHEN wrapped around DEFCONSTANT, and (2) SBCL's
+;;; DEFCONSTANT expansion doesn't seem to behave properly inside
+;;; EVAL-WHEN, so that without this, the +EMPTY-HT-SLOT+ references in
+;;; e.g. DOHASH macroexpansions don't end up being replaced by
+;;; constant values, so that the system dies at cold init because
+;;; '+EMPTY-HT-SLOT+ isn't bound yet. It's hard to fix this properly
+;;; until SBCL's EVAL-WHEN is fixed, which is waiting for the IR1
+;;; interpreter to go away, which is waiting for sbcl-0.7.x..
+(eval-when (:compile-toplevel :load-toplevel :execute)
+ (defconstant +empty-ht-slot+ '%empty-ht-slot%))
+;;; We shouldn't need this mess now that EVAL-WHEN works.
+#+nil (defconstant +empty-ht-slot+ '#.+empty-ht-slot+) ; egads.. See FIXME above.
+;;; KLUDGE: Using a private symbol still leaves us vulnerable to users
+;;; getting nonconforming behavior by messing around with
+;;; DO-ALL-SYMBOLS. That seems like a fairly obscure problem, so for
+;;; now we just don't worry about it. If for some reason it becomes
+;;; worrisome and the magic value needs replacement:
+;;; * The replacement value needs to be LOADable with EQL preserved,
+;;; so that the macroexpansion for WITH-HASH-TABLE-ITERATOR will
+;;; work when compiled into a file and loaded back into SBCL.
+;;; (Thus, just uninterning %EMPTY-HT-SLOT% doesn't work.)
+;;; * The replacement value needs to be acceptable to the
+;;; low-level gencgc.lisp hash table scavenging code.
+;;; * The change will break binary compatibility, since comparisons
+;;; against the value used at the time of compilation are wired
+;;; into FASL files.
+;;; -- WHN 20000622