[iterate-devel] Re: handler-bind macroexpansion and special operators (fwd)
Hi, Sam Steingold wrote:
The only place where it occurs is HANDLER-BIND which is a standard macro though, so I suggest that ITERATE handles HANDLER-BIND specially, not via MACROEXPAND. That's indeed needed for Iterate, ouch! But that's only one issue.
Every program or library which does code-walking and comes across IGNORE-ERRORS or HANDLER-BIND in CLISP will barf on this. Having a useful response from SPECIAL-OPERATOR-P would at least help these to correctly recognize the situation at hand. Which is the second issue: I believe a bug in CLISP's special-operator-p. Regards, Jorg Hohle
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. Bruno
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.
Thomas F. Burdick wrote:
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.
This is a good idea. Would you like to implement this and contribute it to clisp? (If you say no, I will do it.) Bruno
Bruno Haible writes:
Thomas F. Burdick wrote:
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.
This is a good idea. Would you like to implement this and contribute it to clisp? (If you say no, I will do it.)
Nope, I have no hacking time at the moment, and when I get some, I'm going to use it for pending commitments to SBCL. I would like to see CLISP be Iterate-friendly, though.
participants (3)
-
Bruno Haible -
Hoehle, Joerg-Cyril -
Thomas F. Burdick