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

[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

Re: [iterate-devel] Latest stable iterate for cl-pdf
by Hoehle, Joerg-Cyril 13 Dec '04

13 Dec '04

Hi, >>Nevertheless, I can send that to you. >Yes, please do. I will test it on Lispworks and ACL. I've sent that to you separately (the mailing-list software once rejected attachments >40KB). >I just released & uploaded iterate 1.3.pre1. >This release features Joerg-Cyril's patch set What I sent you a month ago is olda already :-) I've since applied more patches. I believe that's a good base for a stable version (despite I know of some more bugs, but nobody noticed in ten years, so it's probably not that harming). The next thing to change is the documentation, which only got very few updates. The code is still based on iterate-1.0.9, without the augment-environment extension (which I haven't yet tested). o TODO .tex: + document in-packages + document else clause + document & test (next var N), note that (iter(generate i in '(1 2 3 4 5)) (princ (next i 2))) \yields 24 + explain loop epilogue: The clauses TERMINATE aka. FINISH, WHILE and UNTIL FINDING-SUCH-THAT cause normal termination of the iteration. FINISH is also used by all of Iterate's FOR clauses. Upon normal termination, the loop epilogue is executed. The FINALLY clause is be used to add to the epilogue. Some other clauses, like LEAVE, ALWAYS or NEVER cause immediate termination of the iteration, without going through the epilogue. Here's most of my changes: ; ---------------- ChangeLog o package.lisp + use declaim + use (export list): (export +clause-names+ '#:iterate) + export defsynonym defmacro-driver o iterate.lisp + (declaim (declaration declare-variables)) + listp -> consp + (prog1 (car body) (pop body)) -> (pop body) + (code-char 0) is portable, #\nul or #\null is not + counting uses '(subst (var exp) #) instead of expr + bang-vars-1: tail-call optimized o for in-package(s) evaluates package(s) argument o for in-package(s) work as generators + use #:start/beginning to (hopefully) work with Allegro modern style + walk-flet: accepts declarations + remove walk-identity and use (x . nil) consistently in *special-form-alist* + ELSE special clause also needs local-binding-check + locally accepts [0..N] declarations + constant? and self-evaluating? accept all self-evaluating forms, including keywords and T/NIL, but no other symbols. + avoid ~< pretty-printer (not in Cormanlisp) in error messages, leave that to the implementation + if-1st-time & special-clause ELSE: type 'boolean instead of symbol + (collect i at 'beginning) barfs, despite man says "may be quoted". + #+clisp "explicit declarations are always placed in the generated code" as the manual says. + #+lispworks multiple-value-bind is recognized (again) + make-next-code N <> 1 generates correct code + (collect i at 'beginning) barfs, despite man says "may be quoted". -> probably change manual: it's not evaluated, so don't quote Same for type: remove code Also here: "(As with ~place~, quoting ~type~ is optional.)" Don't make people believe it could be evaluated! o iter-man.tex + drop note about future with-hashtable/package-iterator + document dsetq value o iterate-pg.lisp + use multiple-value-prog1 o iterate-test.lisp + some testcases ; ---------------- DONE o minor CL optimizations: consp, pop, export, declaim o FOR IN-PACKAGE(S) evaluates package(s) argument o GENERATE IN-PACKAGE(S) works o GENERATE IN-HASHTABLE works o FOR IN-HASHTABLE supports destructuring o FOR IN-PACKAGES was broken because of 'pkgs symbol-types are not evaluated in with-package-iterator and must not be empty => consp o (for vars DO-NEXT) now binds vars o ALWAYS + NEVER work together o FINDING SUCH-THAT may be used with ALWAYS/NEVER or THEREIS o correctly report incompatible accumulation for FINDING SUCH THAT with other clauses, e.g. COLLECT o use DSETQ instead of destructuring-bind for consistency of templates o a few more package exports o added more testcases o (DSETQ (values x nil y)) works o restore v 1.0/2 special/macro order, e.g. change special-form? etc. o in-vector/in-sequence downwards by 2 did not start with last element (iter (for i index-of-vector #(0 1 2 3 4) downto 0 by 2) (collect i)) yields (3 1), expect (4 2 0) by similarity with (iter (for i downfrom 4 by 2) (collect i)) and (iter (for i from 4 downto 0 by 2) (collect i)) Regards, Jörg Höhle

1 0

[iterate-devel] Hello again, and Iterate 1.3.pre1
by Andreas Fuchs 13 Dec '04

13 Dec '04

Hello, everybody! I just released & uploaded iterate 1.3.pre1. Here's to the new version scheme (-: This release features Joerg-Cyril's patch set and the allegro 7.0 beta COND fix. I'm very sorry that this took so long. In addition to being bogged down by work (hacking together php interfaces for a new product that my employer is releasing soon), I was knocked out by a cold/bronchial infection type of thing for the last two weeks. /-: So, anyway, both situations seem to have improved, so I think I'll be able to wear the iterate maintainer hat more often. (-: Have fun, -- Andreas Fuchs, <asf(a)boinkor.net>, asf(a)jabber.at, antifuchs

1 0

Re: [iterate-devel] Latest stable iterate for cl-pdf
by Hoehle, Joerg-Cyril 08 Dec '04

08 Dec '04

Marc Battyani wrote: >I would like to put the latest stable version of iterate in cl-pdf. >I prefer to >put a version in a reasonable stable state rather than the latest one. I can't really tell what a stable one is. 1.0.9 I cannot recommend because of problems with Allegro and Lispworks (and minor ones with CLISP). Mine doesn't qualify for stable because despite having extended the testsuite and applying like two dozen small fixes, it's never been tested outside of CLISP and CormanLisp and it's never been released. Nevertheless, I can send that to you. Maybe one I'd qualify as stable is the original one with just some ANSI-CL renaming (special-operator-p, maybe packages). That has been known to work for a decade. >(I tried to email to Andreas but got no reply so far, maybe a >wrong email) I haven't heard from him since 16th of November, after he said that he would make up a new release with my patches within a few days. It looks like the Internet has lost him?!? :-( Regards, Jörg Höhle.

2 1

Re: [iterate-devel] Iterate error with multiple-value-setq
by Hoehle, Joerg-Cyril 08 Dec '04

08 Dec '04

Stonewall Ballard wrote: >I spent some time tracing the code, and found that multiple-value-bind >is being expanded into multiple-value-bind-call because m-v-b is a >macro. Perhaps it's not in other Lisps. It is a macro in ANSI-CL. >The first test in the cond of WALK (macro-function (car form) *env*) >was true of m-v-b, so it dutifully expanded it and recursed. I believe you missed part of my patch: the macro-function test is the *second* test my patched walk does, because it first checks for the special forms it knows how to handle: ((special-form? (car form)) ; handle known special operators first (walk-special-form form)) ((macro-function (car form) *env*) (walk (macroexpand form *env*))) Therefore, m-v-b should be handled by walk-special-form which then calls walk-m-v-b. macro-function would never be called upon '(m-v-b ...). Could you try to trace both of these and see that they are indeed traversed? There shouldn't be a need to add to *special-form-alist* because m-v-b is there! But it'll only be found if this list is tested first, not macro-function. Regards, Jorg Hohle.

3 2

Re: [iterate-devel] Iterate error with multiple-value-setq
by Hoehle, Joerg-Cyril 29 Nov '04

29 Nov '04

Stonewall, Thanks for the traces and your efforts. The following trace is really what makes me wonder. Inside Iterate, my patch should not expand m-v-b anymore and call walk-m-v-b instead. ((special-form? (car form)) ; handle known special operators first (walk-special-form form)) ((macro-function (car form) *env*) (walk (macroexpand form *env*))) ((special-operator-p (car form)) Yet both macroexpand and macroexpand-1 show that they are called upon m-v-b. So far, I don't understand where this comes from. 0 MACROEXPAND > ... >> SYSTEM::FORM : (MULTIPLE-VALUE-BIND (#:G831 #:G832) (FOO) (LET* NIL (VALUES (SETQ A #:G831) (SETQ B #:G832)))) >> SYSTEM::ENV : #<Environment venv (#<Venv 269101724 B> #<Venv 269101828 A>) fenv NIL benv ((TEST-ITER . #<Block TEST-ITER>)) tenv NIL> 0 MACROEXPAND < ... << VALUE-0 : (SYSTEM::MULTIPLE-VALUE-BIND-CALL (FUNCTION (LAMBDA (&OPTIONAL #:G831 #:G832 &REST #:EXTRA-VALS833) (DECLARE (IGNORE #:EXTRA-VALS833) (COMPILER::WEAK-LAMBDA-NAME COMPILER::DUMMY-LAMBDA)) (LET* NIL (VALUES # #)))) (FOO)) << VALUE-1 : T There are 3 things worth trying (declaim (notinline walk)) before definition or use (declare (optimize debug)) inside walk replace macroexpand in walk with macroexpand-1 >It's interesting that this expansion turns M-V-BIND into M-V-CALL, >while the first two traces above produced a M-V-BIND-CALL. Indeed. >I'm also a little suspicious of your revised definition: >> (or (assoc symbol *special-form-alist*))) >since it has a superfluous OR. I dropped the OR. I'm sorry that my saving a little time and typing caused even more loss of time and typing to you and me. I should have simplified the form after dropping the second or clause. >You can get the package from ><http://www.lispworks.com/downloads/lw-personal-edition.html>. I >imagine that the same error occurs on all the supported platforms. Installing packages cost me a lot of work. I can make no promise as to when I'll be able to do that. But it would be reasonable to install a collection of Lisps here so I can play with comparisons and code that does not work with either CLISP or Corman, when time becomes available. Regards, Jorg.

1 0