From: Christophe R. <cs...@ca...> - 2002-09-05 13:11:54
|
On Wed, Sep 04, 2002 at 06:26:21PM +0400, Alexey Dejneka wrote: > This is a proposition to split FLUSHABLE attribute of known functions > (meaning "its call always may be eliminated") to new FLUSHABLE ("may > be eliminated in unsafe code, or in safe if arguments are of right > types") and UNSAFELY-FLUSHABLE ("may be eliminated in unsafe > code"). The first is attached to side-effect free functions, not > specified to "signal an error", and the second - to functions, which > only "should signal an error" (i.e. must signal in safe code) and have > no specified side effects. > > "flushable-2.patch" contains the implementation of this proposal and > updated version of fndb.lisp. "changes" is a short summary. As you can > see, some functions are now FLUSHABLE, but must signal errors > according to CLHS; many functions must signal an error in safe > code, but are FLUSHABLE :-(. > > This patch has an unpleasant property: some code remains unflushed (in > safe mode), for example, in > > (defun foo (x) > (progn (+ 8 (- x 2)) (* x 3) nil)) > > only + is eliminated, * remains, despite that x in (* x 3) is always > of type NUMBER. Also there are functions which flushability is > disputable. Can you explain why this happens in your implementation? How does this relate (if it does) to the BUGS entry (#35) about non-erroring and argument type? A related thought I had was that it might be nice to provide a hook to the flushable (and possibly other IR1 attributes) functionality; allowing the user to say e.g. (declaim (sb-ext:flushable foo)) (defun foo (x) (some-expensive-computation)) I don't know how feasible this would be. Cheers, Christophe -- Jesus College, Cambridge, CB5 8BL +44 1223 510 299 http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar (str schar arg) (first (last +))) (make-dispatch-macro-character #\! t) (set-dispatch-macro-character #\! #\$ #'pling-dollar) |