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

[iterate-devel] Proposal for manual modification re defclause-sequence
by Mirko Vukovic 12 Feb '10

12 Feb '10

Hello, I recently had an issue of saving iterate extension code in sbcl fasl files. Several folks have commented that the documentation on defclause-sequency could be more explicit on that topic. Thus this email. You can find the whole email thread here: http://common-lisp.net/pipermail/iterate-devel/2010-February/000654.html (the first email in that thread has an attachment with the original problem file). Basically the problem was the following defclause-sequence definition: (defclause-sequence matrix-row matrix-row-index :access-fn (lambda (grid index) (assert (and (grid:gridp grid) (eql (grid:grid-rank grid) 2)) (grid)) (grid:row grid index)) :size-fn (lambda (grid) (assert (and (grid:gridp grid) (eql (grid:grid-rank grid) 2)) (grid)) ... etc. In an interpreted list, such as clisp, there were no problems with this form. But in a compiled list, such as sbcl, the form could be evaluated, but could not be saved in a fasl. Thus compile file and asdf loading did not work. The solution was to quote the lambda forms: (defclause-sequence matrix-row matrix-row-index :access-fn '(lambda (grid index) (assert (and (grid:gridp grid) (eql (grid:grid-rank grid) 2)) (grid)) (grid:row grid index)) :size-fn '(lambda (grid) (assert (and (grid:gridp grid) (eql (grid:grid-rank grid) 2)) (grid)) ... etc. Important to note, sharp-quoting -- #' -- such as in the example code in the manual, did not work. My (very incomplete understanding) is that storing lists (such as '(lambda ...) in fasl's is OK, and iter can figure out what to do with them once read back in. But not storing compiled objects (which a #'(lambda ...) cannot be stored in fasl's. I propose that the documentation be changed, with perhaps a few additional examples. I would be glad to work with one of the developers/maintainers off-line on this issue. Regards, Mirko

1 0

[iterate-devel] Fwd: iterate form evaluates but does not load into sbcl fasl
by Mirko Vukovic 09 Feb '10

09 Feb '10

Hello, (A copy of this email was recently sent to the gsll and sbcl mailing lists). The package gsd <http://repo.or.cz/w/gsd.git>, part of gsll<http://common-lisp.net/project/gsll/>uses iterate to loop over elements of vectors and matrices. I have attached the part of the package that extends iterate to this email. I am having the following issue on sbcl1.034 on RHEL5 64-bit linux, via slime. The following form evaluates OK at the REPL. (iter:iter (iter:for c :matrix-row grid::*array-3-4-double-float* ) (print c)) But, if I embed it into a function: (defun foo () (iter:iter (iter:for c :matrix-row grid::*array-3-4-double-float*) (print c))) it will evaluate OK in slime (C-x C-e), but will not compile (C-c C-c). The returned error is: >>> post-processing/xpdp-post-processing.lisp:75:3: error: Objects of type FUNCTION can't be dumped into fasl files. --> LET* BLOCK TAGBODY PROGN SETQ THE FUNCALL SB-C::%FUNCALL THE --> SB-KERNEL:%COERCE-CALLABLE-TO-FUN ==> #<FUNCTION (LAMBDA #) {1002DD7AD9}> note: The first argument never returns a value. --> LET* BLOCK TAGBODY PROGN SETQ THE FUNCALL SB-C::%FUNCALL THE ==> (SB-KERNEL:%COERCE-CALLABLE-TO-FUN #<FUNCTION # {1002DD7AD9}>) ... more stuff >>> So, it seems that sbcl can digest it, but for some reason cannot write it to a fasl. The macroexpansion of the code above is: (LET* ((#:SEQUENCE120 NIL) (#:LIMIT121 NIL) (C NIL) (#:INDEX119 NIL)) (BLOCK NIL (TAGBODY (PROGN (SETQ #:SEQUENCE120 GRID::*ARRAY-3-4-DOUBLE-FLOAT*) (SETQ #:LIMIT121 (FUNCALL # #:SEQUENCE120)) (SETQ #:INDEX119 -1)) LOOP-TOP-NIL (PROGN (SETQ #:INDEX119 (+ #:INDEX119 1)) (IF (>= #:INDEX119 #:LIMIT121) (GO LOOP-END-NIL)) (SETQ C (FUNCALL # #:SEQUENCE120 #:INDEX119)) (PRINT C)) (PROGN) (GO LOOP-TOP-NIL) LOOP-END-NIL (PROGN)) NIL)) Is this issue due to a malformed extension of iterate, or some misalignment between iterate and sbcl? Thank you, Mirko

4 7

[iterate-devel] Problem with iterate and fare-matcher
by Olof-Joachim Frahm 05 Feb '10

05 Feb '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I've got a problem using iterate with the fare-matcher library (both current versions). In the following code fragment, the function FOO does as it should, matching for the symbol QUIT from the current package. The function BAR however only wraps it inside the iterate macro and then apparently produces slightly wrong code: > (use-package '(#:fare-matcher #:iterate)) > > (defun foo (msg) > (match msg > ('quit 42) > (_ 'else))) > > (foo 'quit) > ;; 42 > > (defun bar (msg) > (iterate > (leave (match msg > ('quit 42) > (_ 'else))))) > > (bar 'quit) > ;; ELSE > (bar 'fare-matcher::quit) > ;; 42 Even with macroexpanding the two definitions I couldn't figure out where this goes wrong, so maybe you have an idea about this. Cheers, Olof - -- Es liegt in der menschlichen Natur, unvenrüntfig zu denken und zu handeln. -- nach Anatole France -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAktsY3kACgkQEiTh585nXwB3jgCeNh5pUyV5D2g5f41z6iA5zJoc lkIAn3ULA6Jy0JKDjKWLi3Q1wXsAzvag =4EaR -----END PGP SIGNATURE-----

1 0

[iterate-devel] Error in array dimension declaration
by Milan Jovanovic 15 Oct '09

15 Oct '09

For example: ITER> (let ((a (make-array 5 :element-type '(unsigned-byte 8)))) (iter (repeat 1) (for a2 = a) (declare (type (simple-array (unsigned-byte 8) (8)) a2)) (print a2))) ; in: LAMBDA NIL ; (ITERATE:ITER (ITERATE:REPEAT 1) (ITERATE:FOR ITERATE::A2 = ITERATE::A) ; (DECLARE ; (TYPE (SIMPLE-ARRAY (UNSIGNED-BYTE 8) (8)) ITERATE::A2)) ; (PRINT ITERATE::A2)) ; ; caught ERROR: ; (in macroexpansion of (ITER (REPEAT 1) (FOR A2 = ...) ...)) ; (hint: For more precise location, try *BREAK-ON-SIGNALS*.) ; The length requested (0) does not match the type restriction in (SIMPLE-ARRAY ; (UNSIGNED-BYTE ; 8) ; (8)). ; (LET ((ITERATE::A (MAKE-ARRAY 5 :ELEMENT-TYPE '(UNSIGNED-BYTE 8)))) ; (ITERATE:ITER (ITERATE:REPEAT 1) (ITERATE:FOR ITERATE::A2 = ITERATE::A) ; (DECLARE (TYPE (SIMPLE-ARRAY # #) ITERATE::A2)) ; (PRINT ITERATE::A2))) ; ; caught STYLE-WARNING: ; The variable A is defined but never used. ; ; compilation unit finished ; caught 1 ERROR condition ; caught 1 STYLE-WARNING condition ; Evaluation aborted. This works : ITER> (let ((a (make-array 5 :element-type '(unsigned-byte 8)))) (iter (repeat 1) (for a2 = a) (declare (type (simple-array (unsigned-byte 8) (*)) a2)) (print a2))) #(0 0 0 0 0) NIL ITER> This is previous form expanded, looks like because of taking care for type inference it's making a array with dimension 0 with declaration that has specified dimension (LET* ((#:COUNT154 NIL) (A2 #())) (DECLARE (TYPE (SIMPLE-ARRAY (UNSIGNED-BYTE 8) (*)) A2)) (BLOCK NIL (TAGBODY (SETQ #:COUNT154 1) LOOP-TOP-NIL (IF (<= #:COUNT154 0) (GO LOOP-END-NIL)) (SETQ A2 A) (PRINT A2) (SETQ #:COUNT154 (1- #:COUNT154)) (GO LOOP-TOP-NIL) LOOP-END-NIL) NIL)) Thanks, Milan

1 0

[iterate-devel] Error in array dimension declaration
by Milan Jovanovic 15 Oct '09

15 Oct '09

For example: ITER> (let ((a (make-array 5 :element-type '(unsigned-byte 8)))) (iter (repeat 1) (for a2 = a) (declare (type (simple-array (unsigned-byte 8) (8)) a2)) (print a2))) ; in: LAMBDA NIL ; (ITERATE:ITER (ITERATE:REPEAT 1) (ITERATE:FOR ITERATE::A2 = ITERATE::A) ; (DECLARE ; (TYPE (SIMPLE-ARRAY (UNSIGNED-BYTE 8) (8)) ITERATE::A2)) ; (PRINT ITERATE::A2)) ; ; caught ERROR: ; (in macroexpansion of (ITER (REPEAT 1) (FOR A2 = ...) ...)) ; (hint: For more precise location, try *BREAK-ON-SIGNALS*.) ; The length requested (0) does not match the type restriction in (SIMPLE-ARRAY ; (UNSIGNED-BYTE ; 8) ; (8)). ; (LET ((ITERATE::A (MAKE-ARRAY 5 :ELEMENT-TYPE '(UNSIGNED-BYTE 8)))) ; (ITERATE:ITER (ITERATE:REPEAT 1) (ITERATE:FOR ITERATE::A2 = ITERATE::A) ; (DECLARE (TYPE (SIMPLE-ARRAY # #) ITERATE::A2)) ; (PRINT ITERATE::A2))) ; ; caught STYLE-WARNING: ; The variable A is defined but never used. ; ; compilation unit finished ; caught 1 ERROR condition ; caught 1 STYLE-WARNING condition ; Evaluation aborted. This works : ITER> (let ((a (make-array 5 :element-type '(unsigned-byte 8)))) (iter (repeat 1) (for a2 = a) (declare (type (simple-array (unsigned-byte 8) (*)) a2)) (print a2))) #(0 0 0 0 0) NIL ITER> This is previous form expanded, looks like because of taking care for type inference it's making a array with dimension 0 with declaration that has specified dimension (LET* ((#:COUNT154 NIL) (A2 #())) (DECLARE (TYPE (SIMPLE-ARRAY (UNSIGNED-BYTE 8) (*)) A2)) (BLOCK NIL (TAGBODY (SETQ #:COUNT154 1) LOOP-TOP-NIL (IF (<= #:COUNT154 0) (GO LOOP-END-NIL)) (SETQ A2 A) (PRINT A2) (SETQ #:COUNT154 (1- #:COUNT154)) (GO LOOP-TOP-NIL) LOOP-END-NIL) NIL)) Thanks, Milan

1 0

Re: [iterate-devel] Warning on Corman CL
by Jonathan Johansen 15 Sep '09

15 Sep '09

Hi again Iterate Developers, Sorry about the noise. I figured out that the major problem was that CCL didn't import symbols like 'iter::for into my package when I eval'ed (use-package '#:iterate) ... grumble grumble grumble. Still, I hope that you consider the small change I proposed that removes a warning in CCL. Cheers, Jonathan Johansen

1 1

[iterate-devel] generate i initially/first ... then ...
by szergling 13 Jun '09

13 Jun '09

Hi all, Does anyone know why the "for ... initially/first ... then ..." etc clauses have no generator equivalents? Refer the documentation, eg http://common-lisp.net/projects/iterate/doc/Variable-Binding-and-Setting.ht… Specifically, there's an extra note that "Also, the for in the above three clauses is misleading, since none is true driver (e.g. none has a corresponding generate form). setting would have been a better choice, but for was used to retain some compatibility with loop." I cannot see why a generator style cannot be made for them too, given the simple and direct mapping of such a form to the 'for'/'setting'(whatever) version. Is this a limitation of iterate's internal macro implementation? I would appreciate any context or pointers to this issue. Yong

1 0

[iterate-devel] Inaccurate *env* for Macroexpansions
by Russ Tyndall 20 May '09

20 May '09

Howdy List, I was having problems when using iterate with the arnesi call/cc codewalker, because variables bound by iterate were not in the environment of any macros in an iterate body form. The codewalker therefore gets that foo is an unbound variable in the iter clause below. To mitigate this, I patched iterate to update the *env* variable to reflect any bindings that iterate is going to make (in sbcl only ATM). Pulling some code from (bsd licenced) http://common-lisp.net/project/bese/repos/arnesi_dev/src/lexenv.lisp, I could probably write an implementation of the two methods I added in all the arnesi supported environments (lispworks /clisp /allegro /cmucl), but I have no way of testing these, so for now I stuck with a tested implementation for sbcl. The semantics of this are fairly straightforward, in that any variable declared textually before a macro call will appear as a lexical variable in the environment passed to the macroexpansion. (loop for foo upfrom 0 while (= foo 0) collect (funcall (lambda () (arnesi:with-call/cc foo)))) => (0) (iter (for foo upfrom 0) (while (= foo 0)) (collect (funcall (lambda () (arnesi:with-call/cc foo))))) => Before my patch this throws unbound variable foo exception / lexical environment is empty After my patch this "correctly" returns (0) Cheers, Russ New patches: [update environment with iterate produced variables Russ Tyndall <russ(a)acceleration.net>**20090520185521 Iterate produces variable bindings that are useful/necessary to macros expanding inside of an iterate body. This particularly effects other codewalkers (such as arnesi). We want (if possible) to update the env we expand macros in to reflect any variables that iterate is lexically binding. ] { hunk ./iterate.lisp 655 +(defgeneric lexical-variables (environment) + (:documentation "Return the names of all the local variables + in ENVIRONMENT. Does not return neither symbol-macrolets nor + ignared variables.") + (:method ((env T)) ())) + +#+sbcl +(defmethod lexical-variables ((environment sb-kernel:lexenv)) + (loop for var-spec in (sb-c::lexenv-vars environment) + when (and (atom (cdr var-spec)) + (not (and (typep (cdr var-spec) 'sb-c::lambda-var) + (sb-c::lambda-var-ignorep (cdr var-spec))))) + collect (car var-spec))) + +(defgeneric update-environment (env) + (:method ((env T)) env) + (:documentation "Updates the lexical environment to reflect all of the available + bindings that iterate has thus far created ")) + +#+sbcl +(defmethod update-environment ((env sb-kernel:lexenv)) + (let ((new-bindings + (loop for (sym . _) in *bindings* + unless (or (null (symbol-package sym)) + (find sym (lexical-variables *env*))) + collect (cons sym T)))) + (sb-c::make-lexenv :default env :vars new-bindings))) + hunk ./iterate.lisp 709 + + ;; Iterate produces variable bindings that are useful/necessary to macros expanding inside + ;; of an iterate body. This particularly effects other codewalkers (such as arnesi). + ;; We want (if possible) to update our environment to reflect any variables that + ;; iterate is lexically binding + (setf *env* (update-environment *env*)) + } Context: [first-time-p bugfix: return-code :body must return list of forms Joerg-Cyril Hoehle <hoehle(a)users.sourceforge.net>**20070525141533 if-first-time not declared obsolete documentation strings for (iter:display-iterate-clauses) complete ] [fix defmacro-driver example in manual Joerg-Cyril Hoehle <hoehle(a)users.sourceforge.net>**20070525081443] [Use @:, @. and two spaces between sentences Joerg-Cyril Hoehle <hoehle(a)users.sourceforge.net>**20070525080932 Move section on predicate (first-time-p) outside of gathering clauses Various typos and some clarifications ] [document *list-end-test* removal in FOR...IN+ON Joerg-Cyril Hoehle <hoehle(a)users.sourceforge.net>**20070525074338] [Renamed back to sharpL-reader attila.lendvai(a)gmail.com**20070506100744] [Fix sharpL reader, add :execute to the eval-when to make (load "iterate" :compiling t) work on clisp attila.lendvai(a)gmail.com**20070506100704] [Convert manual to Texinfo. Luis Oliveira <loliveira(a)common-lisp.net>**20060713142915] [make FOR...IN/ON with dotted lists work like LOOP hoehle(a)users.sourceforge.net**20070503130604 More precisely, FOR ON accepts dotted lists, FOR IN errors out. As a result, iterate::*list-end-test* was eliminated. Behaviour is now constant and does not depend on some special variable. Note: Documentation not yet updated, pending move to Texinfo. ] [walk-tagbody: more testcases Joerg-Cyril Hoehle <hoehle(a)users.sourceforge.net>**20070503095309] [walk-tagbody must not macroexpand symbol/tags among its statements Joerg-Cyril Hoehle <hoehle(a)users.sourceforge.net>**20070404124132] [add ELSE test cases, remove GNU Arch tag Joerg-Cyril Hoehle <hoehle(a)users.sourceforge.net>**20070503093008] [Clean up #L stuff, do not leave #L enabled after loading iterate attila.lendvai(a)gmail.com**20070426153431] [Set *list-end-test* to 'endp instead of 'atom, so (iter (for foo :in something-non-list)) fails instead of silently exists attila.lendvai(a)gmail.com**20070215151652] [wrap code in progns, to avoid possiblity of multiple nil tags in tagbody Henrik Hjelte <henrik(a)evahjelte.com>**20061025145324] [test to detect bug, more than one nil tag in tagbody Henrik Hjelte <henrik(a)evahjelte.com>**20061025145128] [Added release.sh attila.lendvai(a)gmail.com**20060506155953] [TAG 1.4.3 attila.lendvai(a)gmail.com**20060505134701] Patch bundle hash: 62134238d49a98e5dbfb86589229ec0896284f3d

1 1

[iterate-devel] [ELS 2009] Call for participation
by Marco Antoniotti 20 May '09

20 May '09

Apologies for multiple postings.... ************************************************************************ 2nd European Lisp Symposium (ELS 2009) Milan, Italy, May 27-29, 2009 Universita` degli Studi di Milano-Bicocca www.european-lisp-symposium.org ************************************************************************ CALL FOR PARTICIPATION ********************** REGISTRATION IS OPEN AT www.european-lisp-symposium.org. Check out the updated program. Scope and Program Highlights: ***************************** The purpose of the European Lisp Symposium is to provide a forum for the discussion of all aspects of the design, implementation and application of any of the Lisp dialects. We encourage everyone interested in Lisp to participate. The European Lisp Symposium 2009 program includes presentations of high quality papers about novel research results, insights and lessons learned from practical applications, and educational perspectives, all involving Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, and so on. The European Lisp Symposium will feature the following highlights: - Scott McKay of ITA Software will talk about how Lisp use has evolved in his circannual industry work. - Mark Tarver of Lambda Associates will talk about Qi as a viral mutation of the Lisp DNA. - Mauro Pezze` of University of Milan-Bicocca will host a panel on Programmers' Productivity from a Software Engineering point of view. - Joao Pavao Martins and Ernesto Morgado of SISCOG will talk about the role of LISP in the success of SISCOG - Christophe Rhodes will give an unportable tutorial. - Michele Simionato will give a tutorial on Scheme module system and Scheme libraries portability issues across implementations. Social Events: ************** Friday 29th evening, Conference Banquet Saturday 30th morning, Guided tour to the "Futurismo" Exhibit in the center of Milan; 2009 marks the 100th anniversary of the Futurism Manifesto; stretching it, the harbinger of Lisp 50 years later. Program Chair: ************** * Antonio Leitao, Technical University of Lisbon, Portugal Local Chair: ************ * Marco Antoniotti, DISCo, Universita`† Milano Bicocca, Italy Program committee: ****************** * Giuseppe Attardi, Universita` di Pisa , Italy * Pascal Costanza, Vrije Universiteit Brussel, Belgium * Irene Durand, Universite` Bordeaux 1, France * Marc Feeley, Universite` de Montreal, Canada * Ron Garret, Amalgamated Widgets Unlimited, USA * Gregor Kiczales, University of British Columbia, Canada * Scott McKay, ITA Software, Inc., USA * Peter Norvig, Google Inc., USA * Julian Padget, University of Bath, UK * Kent Pitman, HyperMeta, USA * Christian Queinnec, Universite` Pierre et Marie Curie, France * Christophe Rhodes, Goldsmiths College, University of London, UK * Robert Strandh, Universite` Bordeaux 1, France * Mark Tarver, Lambda Associates, UK * Didier Verna, EPITA Research and Development Laboratory, France * JonL White, TheGingerIceCreamFactory of Palo Alto, USA * Taiichi Yuasa, Kyoto University, Japan Registration Fees: ****************** * Students EU100, regular EU220. Registration will include the proceedings, coffee breaks, the symposium dinner and other amenities. Accommodation is not included.

1 0

[iterate-devel] proposed clause (FOR var FROM start BY step LENGTH n)
by Tamas K Papp 01 May '09

01 May '09

Hi everyone, I would like to propose an additional driver clause, that uses the syntax (FOR var FROM start BY step LENGTH n) One would think that one can substitute for this using (FOR var FROM start BY step BELOW (+ start (* step n))) but this has two drawbacks: first, it is inconvenient to use this calculation every time I want to do this, second, rounding errors can creep in for floating-point values, eg: (let* ((n 1000) (step pi) (n-incorrect (iter (for x :from 0 :below (* step n) :by step) (summing 1)))) (- n n-incorrect)) ; gives -1 on my machine Here is the code I wrote to implement it, but since I am not an expert on the internals of iterate, it may be improved; or LENGTH could simply be merged into the current implementation (if that is possible while still preserving the separate counter). (defmacro-driver (FOR var FROM start BY step LENGTH n) "Iteration starting from start, stepping by step, for a total of n steps." ;; Note: reason for this macro is that manual calculation for :below ;; (+ start (* step n)) is tedious, and could also lead to incorrect ;; number of iterations with floating point values. (let ((i (gensym)) ; counts from 0 to (1- n), inclusive (j (gensym)) ; counts from start, by step (kwd (if generate 'generate 'for))) `(progn (with ,i = 0) (with ,j = ,start) (,kwd ,var next (prog2 (when (>= ,i ,n) (terminate)) ,j (incf ,j ,step) (incf ,i)))))) Examples: (iter (for i :from 9 :by 2 :length 5) (collecting i)) ; => (9 11 13 15 17) (iter (generate i :from 9 :by 2 :length 5) (collecting (next i))) ; => (9 11 13 15 17) Can you please include this (or something similar) in the next release? Thanks, Tamas

1 0