> user variable CUSTOM:*DEFINE-EXPORTING*
> initial value: NIL
> when non-nil, macroexpansion of
> DEFUN, DEFMACRO, DEFVAR, DEFCONSTANT, DEFPARAMETER, DEF-CALL-OUT
> (but not DEF-CALL-IN), DEFINE-MODIFY-MACRO, DEFINE-SYMBOL-MACRO,
> DEFSETF, DEF-C-TYPE, DEF-C-ENUM, DEF-C-STRUCT, DEF-C-VAR,
> DEFSTRUCT, DEFCLASS
> will contain an EXPORT form for the symbol defined:
> (EXPORT ',name ,(symbol-package name))
> the variable is checked only at macroexpansion time,
> so when loading a compiled file its value has no effect.
> use case:
> (eval-when (compile eval)
> (setq custom:*define-exporting* t))
> (defvar foo 10)
> (defun bar (x) (+ x foo))
> NOTE: slot accessors (but not slot names) for DEFCLASS, DEFSTRUCT,
> DEF-C-STRUCT, are also exported.
> NOTE: constants defined by DEF-C-ENUM are also exported.
I'm more in favour of an extra package that exports the symbols
EXPORTING:DEFUN, EXPORTING:DEFMACRO, etc.
- It allows leaving the ANSI CL macros unmodified.
- It allows using some of the exporting macros but not all.
- It allows using the non-exporting macro in selected places.
(:shadowing-import-from "EXPORTING" #:defun #:defmacro #:defvar))
(defvar foo 10)
(defun bar (x) (+ x foo))
; This one I don't want to export.
(cl:defun private-password () "as7djqkw")
> (but not DEF-CALL-IN)
Why not? When the called-in function is a generic function, it makes sense
to let other packages attach methods to it; therefore its name should be