+ The same thing happens if the compiler macro expansion of
+ EVERY into MAP is hand-expanded:
+ (defun bar2 (dims)
+ (if (block blockname
+ (map nil
+ (lambda (dim)
+ (let ((pred-value (funcall #'integerp dim)))
+ (unless pred-value
+ (return-from blockname
+ nil))))
+ dims)
+ t)
+ 1
+ 2))
+ CMU CL doesn't have this compiler macro expansion, so it was
+ immune to the original bug in BAR, but once we hand-expand it
+ into BAR2, CMU CL 18c has the same bug. (Run (BAR '(NIL NIL)).)
+
+ The native compiler handles it fine, both in SBCL and in CMU CL.
+
+120a:
+ The compiler incorrectly figures the return type of
+ (DEFUN FOO (FRAME UP-FRAME)
+ (IF (OR (NOT FRAME)
+ T)
+ FRAME
+ "BAR"))
+ as NIL.
+
+ This problem exists in CMU CL 18c too. When I reported it on
+ cmucl-imp@cons.org, Raymond Toy replied 23 Aug 2001 with
+ a partial explanation, but no fix has been found yet.
+
+120b:
+ Even in sbcl-0.pre7.x, which is supposed to be free of the old
+ non-ANSI behavior of treating the function return type inferred
+ from the current function definition as a declaration of the
+ return type from any function of that name, the return type of NIL
+ is attached to FOO in 120a above, and used to optimize code which
+ calls FOO.
+
+121:
+ In sbcl-0.7.14.flaky4.10, the last MAPTEST test case at the end
+ of tests/map-tests.impure.lisp dies with
+ The value
+ #<SB-C::MV-COMBINATION
+ :FUN #<SB-C::REF
+ :LEAF #<SB-C::GLOBAL-VAR
+ :NAME +
+ :TYPE #
+ :WHERE-FROM :DECLARED
+ :KIND :GLOBAL-FUNCTION>>
+ :ARGS (#<SB-C::COMBINATION :FUN # :ARGS (#)>)>
+ is not of type
+ SB-C::COMBINATION.
+ in
+ (SB-C::GENERATE-BYTE-CODE-FOR-REF
+ #<SB-ASSEM:SEGMENT :NAME "Byte Output">
+ #<SB-C::REF
+ :LEAF #<SB-C::GLOBAL-VAR
+ :NAME +
+ :TYPE #<SB-KERNEL:FUNCTION-TYPE (FUNCTION # NUMBER)>
+ :WHERE-FROM :DECLARED
+ :KIND :GLOBAL-FUNCTION>>
+ #<SB-C::CONTINUATION {506AD995}>)