January 2005 - iterate-devel - mailman3.common-lisp.net

Re: [iterate-devel] clisp setf wark around
by Hoehle, Joerg-Cyril 25 Jan '05

25 Jan '05

Hi, Marco Baringer wrote: >This (5 line) patch deals with clisp's ((setf foo) value other-args). Thanks for pointing out the problem. I wrote to clisp-list about it. Do you have a testcase? How did you find out about this bug? >+ (walk `(funcall ',(get (second (car form)) 'system::setf-function) I'll soon submit a patch for Iterate which also works with [9]> (macroexpand-1'(setf (values-list (list a b c)) (foo))) (LET* ((#:G6359 (LIST A B C))) ((SETF VALUES-LIST) (FOO) #:G6359)) ; T which your's doesn't (looking up internals from sys::setf-function is not a good idea). I would probably use walk-cdr or some such. Regards, Jorg Hohle

2 1

Re: [iterate-devel] clisp setf wark around
by Hoehle, Joerg-Cyril 24 Jan '05

24 Jan '05

Thanks for the bug report. Marco wrote: >bese-2004(a)common-lisp.net/iterate--clisp-setf--1.0--patch-1 Great, but do you have an idea how I can look at that 5-liner? My connection to the internet is via a firewall, so I can't use specific protocols (like CVS, unless tunelled by ssh), nor does GNUArch (not installed) help me. By looking around URLs, I found browseable (pseudo-?)directories like but no trace of your patch. All files there are from September 2004. http://common-lisp.net/project/iterate/iterate-devel@common-lisp.net--2004/… Regards, Jorg Hohle.

2 1

[iterate-devel] clisp setf wark around
by Marco Baringer 23 Jan '05

23 Jan '05

bese-2004(a)common-lisp.net/iterate--clisp-setf--1.0--patch-1 This (5 line) patch deals with clisp's ((setf foo) value other-args). -- -Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen

1 0

[iterate-devel] Re: handler-bind macroexpansion and special operators (fwd)
by Hoehle, Joerg-Cyril 18 Jan '05

18 Jan '05

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

3 4

[iterate-devel] Re: handler-bind macroexpansion and special operators (fwd)
by Hoehle, Joerg-Cyril 17 Jan '05

17 Jan '05

Thomas F. Burdirck writes: >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 ...) This is an excellent idea! It goes well with the thought expressed by Duane Rettig (IIRC) in the recent thread that I started in comp.lang.lisp that it's important to know about evaluation rules of special forms. If it looks like a function call, it will work well with analyzing (XREF style) code walkers, and might work with rewriting (Iterate style) code walkers. Regards, Jorg Hohle

1 0

[iterate-devel] AW: handler-bind macroexpansion and special operators (fwd)
by Hoehle, Joerg-Cyril 14 Jan '05

14 Jan '05

Bruno Haible writes: >... SYS::%HANDLER-BIND, >and at this point the code walker would barf as well. Not necessarily. You don't know what the code-walker wants to do (perhaps count function calls, or cross-ref). The code-walker may decide to leave unknown specials alone (most reasonable). However, with the current behaviour, it does not barf on %handler-bind, it barfs on ((error ...) ...) inside it, which is not a correct form, and has no possibility to know where that illegal form comes from. If we had (special-operator-p sys::%handler-bind) -> true in CLISP, then any code-walker would know that it can't continue, which is better than to assume sys::%handler-bind to be a function call when it's clearly not. That's independent on the need to have to add #+clisp(case-of handler-bind) to individual code-walkers, e.g. Iterate. BTW, I also started a thread in cll on this special operator issue Subject: what are allowed special forms? (CLHS clarification) Regards, Jörg.

1 0

[iterate-devel] iterate critique I -- semantics may depend on macroexpansion
by Hoehle, Joerg-Cyril 14 Jan '05

14 Jan '05

Hi, while we are at limitations of Iterate due to the need for code-walking, isn't there some inherent limitation in the attempt to yield varying expansion forms depending on some part deep inside the body? Consider (iterate (when nil (collect 1 into x)) (repeat 3) (finally (return x)) Some user- or implementation-supplied macros may do some primitive value analysis and macroexpand a complete macro form to NIL, 'NIL or (PROGN). For example, the WHEN form above may expand to (PROGN) due to an explicit test for NIL, Iterate would then never see the COLLECT INTO, therefore not produce a binding for X, yielding different semantics to the whole example (X as a free variable). While concretely, I wouldn' expect WHEN to do this, I've seen other macros do this simple kind of optimization, instead of leaving it to the compiler. E.g. Iterate itself contains some constant-folding code. I have no idea how to avoid this situation. LOOP avoids it because it doesn't need a code-walker. Is that a sign of poor design when the intent is a general-purpose library utility? I've tried to think of a variant of Iterate which would require more to be declared in its top-level (e.g. require WITH clauses), while still allowing deeply nested COLLECT expressions etc., but my thoughts have made like no progress in this area. What do you think about such issues? Regards, Jorg Hohle.

1 0

[iterate-devel] handler-bind macroexpansion and special operators (fwd)
by Hoehle, Joerg-Cyril 13 Jan '05

13 Jan '05

Hi, I believe Tayssir John Gabbour's message (included below) reveals a) a bug in clisp, b) a general weakness of portable code walking, failing to handle macros that expand to implementation-specific special operators. For ease of using CC, I send it to clisp-list instead of opening a bugtracker issue. I believe the cause of the bug is that CLISP fails here to respect the obligation AFAIK (where was that in CLHS?) to have all its macros expand into either functions, macros or special forms -- so that code walkers work in CL. However, sys::%handler-bind looks like it must be handled as a special form (or macro) from the expansion example appended below, yet it's not declared as such. [28]> (special-operator-p 'sys::%handler-bind) NIL That could probably be easy to fix in CLISP. Iterate would then issue a warning instead of an error: "the CL implementation says that sys::%handler-bind is a special operator, but Iterate does not know how to handle that. It will not be walked, which means that Iterate clauses inside it will not be seen." -- Better, but still not ideal. How to improve on this? I don't see how to improve on this situation without adding to Iterate specific code for handler-bind. And potentially many other macros could expand to implementation-specific special forms (really?). Code-walking really appears tough -- Portable code walking next to impossible? Sigh (macroexpand-1'(ignore-errors)) (BLOCK #:G3533 (HANDLER-BIND ((ERROR #'(LAMBDA (CONDITION) (RETURN-FROM #:G3533 (VALUES NIL CONDITION))))))) ; T (macroexpand-1 (third (macroexpand-1'(ignore-errors)))) (LET ((#:G3535 #'(LAMBDA NIL (PROGN #'(LAMBDA (CONDITION) (RETURN-FROM #:G3534 (VALUES NIL CONDITION)))))) (#:G3536 #'(LAMBDA NIL (PROGN)))) (LOCALLY (DECLARE (COMPILE)) (SYSTEM::%HANDLER-BIND ((ERROR #'(LAMBDA (CONDITION) (FUNCALL (FUNCALL #:G3535) CONDITION)))) (FUNCALL #:G3536)))) ; T Regards, Jorg Hohle >-----Ursprungliche Nachricht----- >Von: Tayssir John Gabbour >Betreff: [iterate-devel] Bug report: handler-bind in FOR > >Hi all, > >On clisp-2.33.1/win2k, Iterate doesn't like handler-bind. I >don't know what the >issue is; it seems to work in Lispworks, since it was able to compile >cl-typesetting. > >Incidentally, I can't find the link to the mailing list, so >please cc: any >responses to me. ;) > > >;; doesn't work >(iterate:iter (for x = (ignore-errors 3)) > (format t "~&blah: ~S" x) > (until (= x 3))) > >;; works >(iterate:iter (for x = 3) > (format t "~&blah: ~S" x) > (until (= x 3))) > > >Error message: > >Iterate, in (let nil (declare (compile)) > (%handler-bind > ((error #'(lambda (condition) (funcall (funcall g5133) condition)))) > (funcall g5134))): >The form ((error #'(lambda (condition) (funcall (funcall >g5133) condition)))) >is not a valid Lisp expression > [Condition of type simple-error] > >MfG, >Tayssir

2 1

[iterate-devel] Bug report: handler-bind in FOR
by Tayssir John Gabbour 13 Jan '05

13 Jan '05

Hi all, On clisp-2.33.1/win2k, Iterate doesn't like handler-bind. I don't know what the issue is; it seems to work in Lispworks, since it was able to compile cl-typesetting. Incidentally, I can't find the link to the mailing list, so please cc: any responses to me. ;) ;; doesn't work (iterate:iter (for x = (ignore-errors 3)) (format t "~&blah: ~S" x) (until (= x 3))) ;; works (iterate:iter (for x = 3) (format t "~&blah: ~S" x) (until (= x 3))) Error message: Iterate, in (let nil (declare (compile)) (%handler-bind ((error #'(lambda (condition) (funcall (funcall g5133) condition)))) (funcall g5134))): The form ((error #'(lambda (condition) (funcall (funcall g5133) condition)))) is not a valid Lisp expression [Condition of type simple-error] MfG, Tayssir __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0