- &key doc (unfound-result (not found-result)))
- `(progn
- ;; KLUDGE: It would be really nice if we could simply
- ;; do something like this
- ;; (declaim (inline ,name))
- ;; (defun ,name (pred first-seq &rest more-seqs)
- ;; ,doc
- ;; (flet ((map-me (&rest rest)
- ;; (let ((pred-value (apply pred rest)))
- ;; (,found-test pred-value
- ;; (return-from ,name
- ;; ,found-result)))))
- ;; (declare (inline map-me))
- ;; (apply #'map nil #'map-me first-seq more-seqs)
- ;; ,unfound-result))
- ;; but Python doesn't seem to be smart enough about
- ;; inlining and APPLY to recognize that it can use
- ;; the DEFTRANSFORM for MAP in the resulting inline
- ;; expansion. I don't have any appetite for deep
- ;; compiler hacking right now, so I'll just work
- ;; around the apparent problem by using a compiler
- ;; macro instead. -- WHN 20000410
- (defun ,name (pred first-seq &rest more-seqs)
- #!+sb-doc ,doc
- (flet ((map-me (&rest rest)
- (let ((pred-value (apply pred rest)))
- (,found-test pred-value
- (return-from ,name
- ,found-result)))))
- (declare (inline map-me))
- (apply #'map nil #'map-me first-seq more-seqs)
- ,unfound-result))
- ;; KLUDGE: It would be more obviously correct -- but
- ;; also significantly messier -- for PRED-VALUE to be
- ;; a gensym. However, a private symbol really does
- ;; seem to be good enough; and anyway the really
- ;; obviously correct solution is to make Python smart
- ;; enough that we can use an inline function instead
- ;; of a compiler macro (as above). -- WHN 20000410
- ;;
- ;; FIXME: The DEFINE-COMPILER-MACRO here can be
- ;; important for performance, and it'd be good to have
- ;; it be visible throughout the compilation of all the
- ;; target SBCL code. That could be done by defining
- ;; SB-XC:DEFINE-COMPILER-MACRO and using it here,
- ;; moving this DEFQUANTIFIER stuff (and perhaps other
- ;; inline definitions in seq.lisp as well) into a new
- ;; seq.lisp, and moving remaining target-only stuff
- ;; from the old seq.lisp into target-seq.lisp.
- (define-compiler-macro ,name (pred first-seq &rest more-seqs)
- (let ((elements (make-gensym-list (1+ (length more-seqs))))
- (blockname (gensym "BLOCK")))
- (once-only ((pred pred))
- `(block ,blockname
- (map nil
- (lambda (,@elements)
- (let ((pred-value (funcall ,pred ,@elements)))
- (,',found-test pred-value
- (return-from ,blockname
- ,',found-result))))
- ,first-seq
- ,@more-seqs)
- ,',unfound-result)))))))
+ &key doc (unfound-result (not found-result)))
+ `(progn
+ ;; KLUDGE: It would be really nice if we could simply
+ ;; do something like this
+ ;; (declaim (inline ,name))
+ ;; (defun ,name (pred first-seq &rest more-seqs)
+ ;; ,doc
+ ;; (flet ((map-me (&rest rest)
+ ;; (let ((pred-value (apply pred rest)))
+ ;; (,found-test pred-value
+ ;; (return-from ,name
+ ;; ,found-result)))))
+ ;; (declare (inline map-me))
+ ;; (apply #'map nil #'map-me first-seq more-seqs)
+ ;; ,unfound-result))
+ ;; but Python doesn't seem to be smart enough about
+ ;; inlining and APPLY to recognize that it can use
+ ;; the DEFTRANSFORM for MAP in the resulting inline
+ ;; expansion. I don't have any appetite for deep
+ ;; compiler hacking right now, so I'll just work
+ ;; around the apparent problem by using a compiler
+ ;; macro instead. -- WHN 20000410
+ (defun ,name (pred first-seq &rest more-seqs)
+ #!+sb-doc ,doc
+ (flet ((map-me (&rest rest)
+ (let ((pred-value (apply pred rest)))
+ (,found-test pred-value
+ (return-from ,name
+ ,found-result)))))
+ (declare (inline map-me))
+ (apply #'map nil #'map-me first-seq more-seqs)
+ ,unfound-result))
+ ;; KLUDGE: It would be more obviously correct -- but
+ ;; also significantly messier -- for PRED-VALUE to be
+ ;; a gensym. However, a private symbol really does
+ ;; seem to be good enough; and anyway the really
+ ;; obviously correct solution is to make Python smart
+ ;; enough that we can use an inline function instead
+ ;; of a compiler macro (as above). -- WHN 20000410
+ ;;
+ ;; FIXME: The DEFINE-COMPILER-MACRO here can be
+ ;; important for performance, and it'd be good to have
+ ;; it be visible throughout the compilation of all the
+ ;; target SBCL code. That could be done by defining
+ ;; SB-XC:DEFINE-COMPILER-MACRO and using it here,
+ ;; moving this DEFQUANTIFIER stuff (and perhaps other
+ ;; inline definitions in seq.lisp as well) into a new
+ ;; seq.lisp, and moving remaining target-only stuff
+ ;; from the old seq.lisp into target-seq.lisp.
+ (define-compiler-macro ,name (pred first-seq &rest more-seqs)
+ (let ((elements (make-gensym-list (1+ (length more-seqs))))
+ (blockname (gensym "BLOCK")))
+ (once-only ((pred pred))
+ `(block ,blockname
+ (map nil
+ (lambda (,@elements)
+ (let ((pred-value (funcall ,pred ,@elements)))
+ (,',found-test pred-value
+ (return-from ,blockname
+ ,',found-result))))
+ ,first-seq
+ ,@more-seqs)
+ ,',unfound-result)))))))