;;; -*- Mode:LISP; Package:USER; Readtable:CL -*- ;;;The compiler croaks on this: (defun flen (f n) (with-open-file (s f) s (= n 4))) ;;;And these all (using major sub-forms of the WITH-OPEN-FILE) compile fine: (defun flen (n) (let() (= n 4))) (defun flen (f n) (unwind-protect f (= n 4))) (defun flen (f n) (multiple-value-prog1 (let ((x f)) (= n 4) x) (and f t))) (defun flen (f n) (let ((s 1)) (multiple-value-prog1 (let ((x f)) (= n 4) x) (and f t)) s)) ;;;More fun with optimizers: (defun flen (n) (=) (= 1) (= x) (= n 4)) #| Peter, I have been working for several hours on an interesting problem. I see the reasons, and there are stupid workarounds (which I have not pursued). Look at the sample code above. The first one's taken from the bug database; one of the few priority 1 problems left. Note the compiler blowing out with a 'function not defined error'. The compiler has a problem with three microcoded functions. Well, it turns out that the three compiler optimizers all blow up if the pertinent sections get called (that is, they only win if they punt): (eval (print (COMPILER:<-OPTIMIZER '(< 3 4)) *query-io*)) (eval (print (COMPILER:<-OPTIMIZER '(> 3 4)) *query-io*)) (eval (print (COMPILER:<-OPTIMIZER '(= 3 4)) *query-io*)) But you don't always get there; the working examples above all had the INTERNAL-foo call optimized out on the second pass. Strangely enough, an adjacent microcode function with a similar optimizer *does* work fine: (eval (print (COMPILER:char-equal-OPTIMIZER '(char-equal 65 65)) *query-io*)) Here are the definitions in DEFMIC: (DEFMIC (INTERNAL-< . M-<) 411 (NUM1 NUM2) T) (DEFMIC (INTERNAL-> . M->) 412 (NUM1 NUM2) T) (DEFMIC (INTERNAL-= . M-=) 413 (NUM1 NUM2) T) (DEFMIC INTERNAL-CHAR-EQUAL 414 (CH1 CH2) T) {Is the big win for INTERNAL-CHAR-EQUAL the fact that the instruction name is the same as the LISP function?} OK, having shot my wad on this fascinating microcode topic, I looked around in LISP. All four of those functions get the appropriate COMPILER:Q properties. But, wait! The three broken ones aren't interned in GLOBAL; they're present directly in SYSTEM-INTERNALS. This must be a bug; other microcoded functions that are happily being optimized are in GLOBAL. So -- how did they not get into GLOBAL? ...And how do we put them back in, and put the lid on? I wonder if there are more such? I would like your help, and I want to work with you on this one... -- Keith |#