[iterate-devel] [clisp-list] Re: handler-bind macroexpansion and special operators (fwd)

[Thomas F. Burdick]

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.