Bruno Haible writes:
Joerg-Cyril Hoehle wrote:
Every program or library which does code-walking and comes across IGNORE-ERRORS or HANDLER-BIND in CLISP will barf on this.
Yes. Like HANDLER-BIND, like COMPILER-LET, is a primitive that cannot be emulated using macroexpansions in clisp.
Having a useful response from SPECIAL-OPERATOR-P would at least help these to correctly recognize the situation at hand.
I don't agree. The purpose of the statement in CLHS 3.1.2.1.2.2
"An implementation is free to implement any macro operator as a special operator, but only if an equivalent definition of the macro is also provided."
is obviously that code walkers will use the macro definition and not have special code for HANDLER-BIND. But this macro definition cannot do anything else than expand into something containing SYS::%HANDLER-BIND, and at this point the code walker would barf as well.
So the code walkers need a bit of #+clisp code for either HANDLER-BIND or SYS::%HANDLER-BIND. The former is better, since HANDLER-BIND is a documented symbol whose meaning won't change.
For a fix to the immediate problem, why not change the syntax of sys::%handler-bind to match normal function call syntax:
(%handler-bind body-thunk 'condition1 handler1 'condition2 handler2 ...)
instead of
(%handler-bind ((condition1 handler1) (condition2 handler2) ...) (funcall body-thunk))
Even if %handler-bind can't be written as a primitive function (I don't know CLISP's internals, so I'll have to take your word for it), this should be good enough for most code walkers.