+ ;; Node, allocating closure for this lambda. May be NIL when we are
+ ;; sure that no closure is needed.
+ (allocator nil :type (or null combination))
+ ;; various rare miscellaneous info that drives code generation & stuff
+ (plist () :type list)
+ ;; xref information for this functional (only used for functions with an
+ ;; XEP)
+ (xref () :type list)
+ ;; True if this functional was created from an inline expansion
+ (inline-expanded nil :type boolean))
+(defprinter (functional :identity t)
+ %source-name
+ %debug-name
+ #!+sb-show id)
+
+;;; Is FUNCTIONAL LET-converted? (where we're indifferent to whether
+;;; it returns one value or multiple values)
+(defun functional-letlike-p (functional)
+ (member (functional-kind functional)
+ '(:let :mv-let)))
+
+;;; Is FUNCTIONAL sorta LET-converted? (where even an :ASSIGNMENT counts)
+;;;
+;;; FIXME: I (WHN) don't understand this one well enough to give a good
+;;; definition or even a good function name, it's just a literal copy
+;;; of a CMU CL idiom. Does anyone have a better name or explanation?
+(defun functional-somewhat-letlike-p (functional)
+ (or (functional-letlike-p functional)
+ (eql (functional-kind functional) :assignment)))
+
+;;; FUNCTIONAL name operations
+(defun functional-debug-name (functional)
+ ;; FUNCTIONAL-%DEBUG-NAME takes precedence over FUNCTIONAL-SOURCE-NAME
+ ;; here because we want different debug names for the functions in
+ ;; DEFUN FOO and FLET FOO even though they have the same source name.
+ (or (functional-%debug-name functional)
+ ;; Note that this will cause an error if the function is
+ ;; anonymous. In SBCL (as opposed to CMU CL) we make all
+ ;; FUNCTIONALs have debug names. The CMU CL code didn't bother
+ ;; in many FUNCTIONALs, especially those which were likely to be
+ ;; optimized away before the user saw them. However, getting
+ ;; that right requires a global understanding of the code,
+ ;; which seems bad, so we just require names for everything.
+ (leaf-source-name functional)))