((list-of-symbols-p vars)
(let ((temps (make-gensym-list (length vars))))
`(multiple-value-bind ,temps ,value-form
- ,@(mapcar #'(lambda (var temp)
- `(setq ,var ,temp))
+ ,@(mapcar (lambda (var temp)
+ `(setq ,var ,temp))
vars temps)
,(car temps))))
(t (error "Vars is not a list of symbols: ~S" vars))))
(unless (symbol-package (fun-name-block-name name))
(warn "DEFUN of uninterned symbol ~S (tricky for GENESIS)" name))
(multiple-value-bind (forms decls doc) (parse-body body)
- (let* ((lambda `(lambda ,args
- ,@decls
- (block ,(fun-name-block-name name)
- ,@forms)))
+ (let* (;; stuff shared between LAMBDA and INLINE-LAMBDA and NAMED-LAMBDA
+ (lambda-guts `(,args
+ ,@decls
+ (block ,(fun-name-block-name name)
+ ,@forms)))
+ (lambda `(lambda ,@lambda-guts))
+ #-sb-xc-host
+ (named-lambda `(named-lambda ,name ,@lambda-guts))
(inline-lambda
(cond (;; Does the user not even want to inline?
(not (inline-fun-name-p name))
;; simplified way.
`(sb!c:lambda-with-lexenv
nil nil nil ; i.e. no DECLS, no MACROS, no SYMMACS
- ,@(rest lambda))))))
+ ,@lambda-guts)))))
`(progn
;; In cross-compilation of toplevel DEFUNs, we arrange
;; for the LAMBDA to be statically linked by GENESIS.
+ ;;
+ ;; It may seem strangely inconsistent not to use NAMED-LAMBDA
+ ;; here instead of LAMBDA. The reason is historical:
+ ;; COLD-FSET was written before NAMED-LAMBDA, and has special
+ ;; logic of its own to notify the compiler about NAME.
#+sb-xc-host
(cold-fset ,name ,lambda)
;; where the compiled LAMBDA first appears. In
;; cross-compilation, we manipulate the
;; previously-statically-linked LAMBDA here.
- #-sb-xc-host ,lambda
+ #-sb-xc-host ,named-lambda
#+sb-xc-host (fdefinition ',name)
,doc)))))
#-sb-xc-host
(/show0 "redefining NAME in %DEFUN")
(style-warn "redefining ~S in DEFUN" name))
(setf (sb!xc:fdefinition name) def)
+
+ ;; FIXME: I want to do this here (and fix bug 137), but until the
+ ;; breathtaking CMU CL function name architecture is converted into
+ ;; something sane, (1) doing so doesn't really fix the bug, and
+ ;; (2) doing probably isn't even really safe.
+ #+nil (setf (%fun-name def) name)
+
(when doc
;; FIXME: This should use shared SETF-name-parsing logic.
(if (and (consp name) (eq (first name) 'setf))
\f
;;;; iteration constructs
-;;; (These macros are defined in terms of a function DO-DO-BODY which
+;;; (These macros are defined in terms of a function FROB-DO-BODY which
;;; is also used by SB!INT:DO-ANONYMOUS. Since these macros should not
;;; be loaded on the cross-compilation host, but SB!INT:DO-ANONYMOUS
-;;; and DO-DO-BODY should be, these macros can't conveniently be in
-;;; the same file as DO-DO-BODY.)
+;;; and FROB-DO-BODY should be, these macros can't conveniently be in
+;;; the same file as FROB-DO-BODY.)
(defmacro-mundanely do (varlist endlist &body body)
#!+sb-doc
"DO ({(Var [Init] [Step])}*) (Test Exit-Form*) Declaration* Form*
are evaluated as a PROGN, with the result being the value of the DO. A block
named NIL is established around the entire expansion, allowing RETURN to be
used as an alternate exit mechanism."
- (do-do-body varlist endlist body 'let 'psetq 'do nil))
+ (frob-do-body varlist endlist body 'let 'psetq 'do nil))
(defmacro-mundanely do* (varlist endlist &body body)
#!+sb-doc
"DO* ({(Var [Init] [Step])}*) (Test Exit-Form*) Declaration* Form*
the Exit-Forms are evaluated as a PROGN, with the result being the value
of the DO. A block named NIL is established around the entire expansion,
allowing RETURN to be used as an laternate exit mechanism."
- (do-do-body varlist endlist body 'let* 'setq 'do* nil))
+ (frob-do-body varlist endlist body 'let* 'setq 'do* nil))
;;; DOTIMES and DOLIST could be defined more concisely using
;;; destructuring macro lambda lists or DESTRUCTURING-BIND, but then