John Fremlin's blog: Common Common Lisp myths about declaim

Posted 2009-07-25 07:19:00 GMT

1 watching live

There are some unfortunate myths and misunderstandings about the Common Lisp form declaim. This form is generally implemented as a (eval-when (...) (proclaim ...)) or similar. It adds compile-time declarations or changes optimization priorities.

Because its effects may persist globally, it's not necessarily a good thing to use (declaim (optimize ...)) to change the compiler's code generation priorities in a library. A reasonable alternative (used in ironclad) is to put a (declare #.(my-optimize-settings-for-high-performance-functions)) at the head of all the functions for which you believe you have a better notion than the user — cl-ppcre uses (declare #.*standard-optimize-settings*) in a similar way. Alternatively, you could wrap all you definitions in a locally form like (locally (declare (optimize ...)) (defun ...) (defun ...) ...).

(The move to xvcb should help resolve all this.)

For an example of a strange myth, some people think that you should wrap it like this (eval-when (:compile-toplevel) (declaim ...)). That this affects Allegro is utter rubbish. I don't know of any compiler that requires this as it would seem to contravene (at least the intent of) the spec for declaim.

Secondly, one thing that I have often done myself and also seen often (for example in cl-cont) is the (declaim (inline function-name)) placed after the definition of the function (I submitted a patch to fix this). The spec clearly states that the (declaim (inline function-name)) should precede the definition of the function so that the compiler has a chance to store the information necessary for inlining. This really affects SBCL. (As an aside, Allegro 8's compiler is too stupid to inline user functions without extra magic so it's not relevant there.)

Post a comment