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
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
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)
I don't know how feasible this would be.
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)