+ ;; (For public access to this slot, use LEAF-DEBUG-NAME.)
+ ;;
+ ;; the name of FUNCTIONAL for debugging purposes, or NIL if we
+ ;; should just let the SOURCE-NAME fall through
+ ;;
+ ;; Unlike the SOURCE-NAME slot, this slot's value should never
+ ;; affect ordinary code behavior, only debugging/diagnostic behavior.
+ ;;
+ ;; The value of this slot can be anything, except that it shouldn't
+ ;; be a legal function name, since otherwise debugging gets
+ ;; confusing. (If a legal function name is a good name for the
+ ;; function, it should be in %SOURCE-NAME, and then we shouldn't
+ ;; need a %DEBUG-NAME.) In SBCL as of 0.pre7.87, it's always a
+ ;; string unless it's NIL, since that's how CMU CL represented debug
+ ;; names. However, eventually I (WHN) think it we should start using
+ ;; list values instead, since they have much nicer print properties
+ ;; (abbreviation, skipping package prefixes when unneeded, and
+ ;; renaming package prefixes when we do things like renaming SB!EXT
+ ;; to SB-EXT).
+ ;;
+ ;; E.g. for the function which implements (DEFUN FOO ...), we could
+ ;; have
+ ;; %SOURCE-NAME=FOO
+ ;; %DEBUG-NAME=NIL
+ ;; for the function which implements the top level form
+ ;; (IN-PACKAGE :FOO) we could have
+ ;; %SOURCE-NAME=NIL
+ ;; %DEBUG-NAME="top level form (IN-PACKAGE :FOO)"
+ ;; for the function which implements FOO in
+ ;; (DEFUN BAR (...) (FLET ((FOO (...) ...)) ...))
+ ;; we could have
+ ;; %SOURCE-NAME=FOO
+ ;; %DEBUG-NAME="FLET FOO in BAR"
+ ;; and for the function which implements FOO in
+ ;; (DEFMACRO FOO (...) ...)
+ ;; we could have
+ ;; %SOURCE-NAME=FOO (or maybe .ANONYMOUS.?)
+ ;; %DEBUG-NAME="DEFMACRO FOO"
+ (%debug-name nil
+ :type (or null (not (satisfies legal-fun-name-p)))
+ :read-only t)