Zach Kost-Smith | 25 Feb 17:18 2015
Picon

Re: iterate-1.4.3 doesn't compile under SBCL-1.2.8

I do see the same error and cannot build Iterate 1.4.3, but that was all a bit of a surprise.  That is because I use Iterate every day and trust that it will always work, and it has, if you are using the Quicklisp version of the library.  So to you, Helmut, I would suggest that you start using Quicklisp (http://www.quicklisp.org/) and bask in the limited amount of quality control that it has.

The bigger question here is what is going on with darcs/current tarball/Quicklisp?

You don't see this problem with Quicklisp version of iterate, which should be taken from the darcs repo automatically on regular periods.  So I cloned the darcs repo and (other than some misterious "hash failed" errors) it is identical to the quicklisp version and, naturally, it loads fine.  The last time the quicklisp version was updated was sometime in June of last year which is after the last commit in the log of the darcs repo (on April 22: "make the #L reader macro standard conformant by not assuming anything about the representation of quasiquoted forms") .  So what is 1.4.3?  A diff between the Quicklisp version and the 1.4.3 version shows that there are substantial changes.  I really don't know much about Darcs, but I assume that there is some other branch out there or something which is where "1.4.3" resides.  Is this a rogue or development branch that somebody is accidentally giving as the current version on common-lisp.net?

Zach KS


On Wed, Feb 25, 2015 at 6:02 AM, Helmut Jarausch <jarausch <at> skynet.be> wrote:
Hi,

please bear in mind that I'm Lisp newbee.
When I try to load iterate (1.4.3) I get the  warnings and one error below.

Many thanks for a hint,
Helmut


; in: DEFMACRO WITH-TEMPORARY
;     `(LET ((,ITERATE::OLD-VAR ITERATE::*TEMPS-IN-USE*))
;        (UNWIND-PROTECT
;            (LET ,(MAPCAR #'(LAMBDA # `#) ITERATE::VARS)
;              . ,ITERATE::BODY)
;          (SETQ ITERATE::*TEMPS-IN-USE* ,ITERATE::OLD-VAR)))
; --> SB-IMPL::|List| SB-IMPL::|List| SB-IMPL::|List*| MAPCAR LET LET
; --> SB-INT:DO-ANONYMOUS BLOCK LET TAGBODY TAGBODY SB-KERNEL:%RPLACD
; --> SETQ THE LIST CONS
; ==>
;   (SB-C::%FUNCALL #:G2 (CAR #:G1))
;
; caught WARNING:
;   function called with one argument, but wants exactly zero
;   See also:
;     The ANSI Standard, Section 3.2.2.3

; file: /home/jarausch/Lisp_My/TEST/iterate.lisp
; in: DEFMACRO WITH-TEMPORARY
;     `(LET ((,ITERATE::OLD-VAR ITERATE::*TEMPS-IN-USE*))
;        (UNWIND-PROTECT
;            (LET ,(MAPCAR #'(LAMBDA # `#) ITERATE::VARS)
;              . ,ITERATE::BODY)
;          (SETQ ITERATE::*TEMPS-IN-USE* ,ITERATE::OLD-VAR)))
; --> SB-IMPL::|List| SB-IMPL::|List| SB-IMPL::|List*| MAPCAR LET
; --> SB-KERNEL:%COERCE-CALLABLE-TO-FUN FUNCTION SB-INT:QUASIQUOTE
; ==>
;   (SB-IMPL::|List*| ITERATE::!1 '((ITERATE::GET-FREE-TEMP)))
;
; caught WARNING:
;   undefined variable: !1
;

The following errors occurs in several functions

; in: DEFUN RETURN-COLLECTION-CODE
;     (ITERATE::WITH-TEMPORARY ITERATE::TEMP-VAR
;       (LET* ((ITERATE::UPDATE-CODE
;               `(IF ,ITERATE::COLLECT-VAR
;                    #
;                    #))
;              (ITERATE::MAIN-CODE (COND # # #)))
;         (ITERATE::RETURN-CODE :BODY
;                               `((PROGN
;                                  ,.ITERATE::MAIN-CODE
;                                  ,ITERATE::COLLECT-VAR))
;                               :FINAL
;                               (IF (EQ ITERATE::RESULT-TYPE 'LIST)
;                                   NIL
;                                   `(#)))))
;
; caught ERROR:
;   during macroexpansion of
;   (WITH-TEMPORARY TEMP-VAR
;     (LET* #
;       #)).


_______________________________________________
Iterate-devel mailing list
Iterate-devel <at> common-lisp.net
https://mailman.common-lisp.net/cgi-bin/mailman/listinfo/iterate-devel

<div>
<div dir="ltr">
<div>I do see the same error and cannot build Iterate 1.4.3, but that was all a bit of a surprise.&nbsp; That is because I use Iterate every day and trust that it will always work, and it has, if you are using the Quicklisp version of the library.&nbsp; So to you, Helmut, I would suggest that you start using Quicklisp (<a href="http://www.quicklisp.org/">http://www.quicklisp.org/</a>) and bask in the limited amount of quality control that it has.<br><br>The bigger question here is what is going on with darcs/current tarball/Quicklisp?<br><br>
</div>
<div>You don't see this problem with Quicklisp version of iterate, which should be taken from the darcs repo automatically on regular periods.&nbsp; So I cloned the darcs repo and (other than some misterious "hash failed" errors) it is identical to the quicklisp version and, naturally, it loads fine.&nbsp; The last time the quicklisp version was updated was sometime in June of last year which is after the last commit in the log of the darcs repo (on April 22: "make the #L reader macro standard conformant by not assuming anything about the representation of quasiquoted forms") .&nbsp; So what is 1.4.3?&nbsp; A diff between the Quicklisp version and the 1.4.3 version shows that there are substantial changes.&nbsp; I really don't know much about Darcs, but I assume that there is some other branch out there or something which is where "1.4.3" resides.&nbsp; Is this a rogue or development branch that somebody is accidentally giving as the current version on <a href="http://common-lisp.net">common-lisp.net</a>?<br><br>
</div>
<div>Zach KS<br>
</div>
<div><br></div>
</div>
<div class="gmail_extra">
<br><div class="gmail_quote">On Wed, Feb 25, 2015 at 6:02 AM, Helmut Jarausch <span dir="ltr">&lt;<a href="mailto:jarausch <at> skynet.be" target="_blank">jarausch <at> skynet.be</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">Hi,<br><br>
please bear in mind that I'm Lisp newbee.<br>
When I try to load iterate (1.4.3) I get the&nbsp; warnings and one error below.<br><br>
Many thanks for a hint,<br>
Helmut<br><br><br>
; in: DEFMACRO WITH-TEMPORARY<br>
;&nbsp; &nbsp; &nbsp;`(LET ((,ITERATE::OLD-VAR ITERATE::*TEMPS-IN-USE*))<br>
;&nbsp; &nbsp; &nbsp; &nbsp; (UNWIND-PROTECT<br>
;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; (LET ,(MAPCAR #'(LAMBDA # `#) ITERATE::VARS)<br>
;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; . ,ITERATE::BODY)<br>
;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; (SETQ ITERATE::*TEMPS-IN-USE* ,ITERATE::OLD-VAR)))<br>
; --&gt; SB-IMPL::|List| SB-IMPL::|List| SB-IMPL::|List*| MAPCAR LET LET<br>
; --&gt; SB-INT:DO-ANONYMOUS BLOCK LET TAGBODY TAGBODY SB-KERNEL:%RPLACD<br>
; --&gt; SETQ THE LIST CONS<br>
; ==&gt;<br>
;&nbsp; &nbsp;(SB-C::%FUNCALL #:G2 (CAR #:G1))<br>
;<br>
; caught WARNING:<br>
;&nbsp; &nbsp;function called with one argument, but wants exactly zero<br>
;&nbsp; &nbsp;See also:<br>
;&nbsp; &nbsp; &nbsp;The ANSI Standard, Section 3.2.2.3<br><br>
; file: /home/jarausch/Lisp_My/TEST/iterate.lisp<br>
; in: DEFMACRO WITH-TEMPORARY<br>
;&nbsp; &nbsp; &nbsp;`(LET ((,ITERATE::OLD-VAR ITERATE::*TEMPS-IN-USE*))<br>
;&nbsp; &nbsp; &nbsp; &nbsp; (UNWIND-PROTECT<br>
;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; (LET ,(MAPCAR #'(LAMBDA # `#) ITERATE::VARS)<br>
;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; . ,ITERATE::BODY)<br>
;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; (SETQ ITERATE::*TEMPS-IN-USE* ,ITERATE::OLD-VAR)))<br>
; --&gt; SB-IMPL::|List| SB-IMPL::|List| SB-IMPL::|List*| MAPCAR LET<br>
; --&gt; SB-KERNEL:%COERCE-CALLABLE-TO-FUN FUNCTION SB-INT:QUASIQUOTE<br>
; ==&gt;<br>
;&nbsp; &nbsp;(SB-IMPL::|List*| ITERATE::!1 '((ITERATE::GET-FREE-TEMP)))<br>
;<br>
; caught WARNING:<br>
;&nbsp; &nbsp;undefined variable: !1<br>
;<br><br>
The following errors occurs in several functions<br><br>
; in: DEFUN RETURN-COLLECTION-CODE<br>
;&nbsp; &nbsp; &nbsp;(ITERATE::WITH-TEMPORARY ITERATE::TEMP-VAR<br>
;&nbsp; &nbsp; &nbsp; &nbsp;(LET* ((ITERATE::UPDATE-CODE<br>
;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;`(IF ,ITERATE::COLLECT-VAR<br>
;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; #<br>
;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; #))<br>
;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; (ITERATE::MAIN-CODE (COND # # #)))<br>
;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;(ITERATE::RETURN-CODE :BODY<br>
;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;`((PROGN<br>
;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ,.ITERATE::MAIN-CODE<br>
;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ,ITERATE::COLLECT-VAR))<br>
;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;:FINAL<br>
;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;(IF (EQ ITERATE::RESULT-TYPE 'LIST)<br>
;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;NIL<br>
;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;`(#)))))<br>
;<br>
; caught ERROR:<br>
;&nbsp; &nbsp;during macroexpansion of<br>
;&nbsp; &nbsp;(WITH-TEMPORARY TEMP-VAR<br>
;&nbsp; &nbsp; &nbsp;(LET* #<br>
;&nbsp; &nbsp; &nbsp; &nbsp;#)).<br><br><br>
_______________________________________________<br>
Iterate-devel mailing list<br><a href="mailto:Iterate-devel <at> common-lisp.net">Iterate-devel <at> common-lisp.net</a><br><a href="https://mailman.common-lisp.net/cgi-bin/mailman/listinfo/iterate-devel" target="_blank">https://mailman.common-lisp.net/cgi-bin/mailman/listinfo/iterate-devel</a><br>
</blockquote>
</div>
<br>
</div>
</div>
Helmut Jarausch | 25 Feb 13:02 2015
Picon

iterate-1.4.3 doesn't compile under SBCL-1.2.8

Hi,

please bear in mind that I'm Lisp newbee.
When I try to load iterate (1.4.3) I get the  warnings and one error below.

Many thanks for a hint,
Helmut

; in: DEFMACRO WITH-TEMPORARY
;     `(LET ((,ITERATE::OLD-VAR ITERATE::*TEMPS-IN-USE*))
;        (UNWIND-PROTECT
;            (LET ,(MAPCAR #'(LAMBDA # `#) ITERATE::VARS)
;              . ,ITERATE::BODY)
;          (SETQ ITERATE::*TEMPS-IN-USE* ,ITERATE::OLD-VAR)))
; --> SB-IMPL::|List| SB-IMPL::|List| SB-IMPL::|List*| MAPCAR LET LET 
; --> SB-INT:DO-ANONYMOUS BLOCK LET TAGBODY TAGBODY SB-KERNEL:%RPLACD 
; --> SETQ THE LIST CONS 
; ==>
;   (SB-C::%FUNCALL #:G2 (CAR #:G1))
; 
; caught WARNING:
;   function called with one argument, but wants exactly zero
;   See also:
;     The ANSI Standard, Section 3.2.2.3

; file: /home/jarausch/Lisp_My/TEST/iterate.lisp
; in: DEFMACRO WITH-TEMPORARY
;     `(LET ((,ITERATE::OLD-VAR ITERATE::*TEMPS-IN-USE*))
;        (UNWIND-PROTECT
;            (LET ,(MAPCAR #'(LAMBDA # `#) ITERATE::VARS)
;              . ,ITERATE::BODY)
;          (SETQ ITERATE::*TEMPS-IN-USE* ,ITERATE::OLD-VAR)))
; --> SB-IMPL::|List| SB-IMPL::|List| SB-IMPL::|List*| MAPCAR LET 
; --> SB-KERNEL:%COERCE-CALLABLE-TO-FUN FUNCTION SB-INT:QUASIQUOTE 
; ==>
;   (SB-IMPL::|List*| ITERATE::!1 '((ITERATE::GET-FREE-TEMP)))
; 
; caught WARNING:
;   undefined variable: !1
; 

The following errors occurs in several functions

; in: DEFUN RETURN-COLLECTION-CODE
;     (ITERATE::WITH-TEMPORARY ITERATE::TEMP-VAR
;       (LET* ((ITERATE::UPDATE-CODE
;               `(IF ,ITERATE::COLLECT-VAR
;                    #
;                    #))
;              (ITERATE::MAIN-CODE (COND # # #)))
;         (ITERATE::RETURN-CODE :BODY
;                               `((PROGN
;                                  ,.ITERATE::MAIN-CODE
;                                  ,ITERATE::COLLECT-VAR))
;                               :FINAL
;                               (IF (EQ ITERATE::RESULT-TYPE 'LIST)
;                                   NIL
;                                   `(#)))))
; 
; caught ERROR:
;   during macroexpansion of
;   (WITH-TEMPORARY TEMP-VAR
;     (LET* #
;       #)).

Ryan Davis | 2 Jan 21:50 2013
Picon

small feature request w/ patch

I'm trying to organize my workplace lisp libraries (from a cobble of
source checkouts and asdf-installed stuff), and we had a small patch to
iterate that I'd like in the mainline so we can consume iterate via
quicklisp.

It adds a new restart in #'ambiguity-check-clause to delete one of the
clauses to resolve the ambiguity. This has been very helpful when
developing and debugging new iterate drivers, and I don't think it has
any other relevant effects.

Attached is a dpatch created with `darcs send -O`, but if that doesn't
work here's the diff:

diff -rN old-iterate/iterate.lisp new-iterate/iterate.lisp
1322c1322,1323
<       (error "Iterate: Inserting clause ~a would create ~
---
>       (restart-case
>             (error "Iterate: Inserting clause ~a would create ~
1324c1325,1328
<              kw1 kw2))))
---
>                    kw1 kw2)
>           (delete-conflict ()
>             :report "Delete the original clause"
>             (remove-clause kw2))))))

Thanks,

-- 
Ryan Davis
Acceleration.net
Director of Programming Services
2831 NW 41st street, suite B
Gainesville, FL 32606

Office: 352-335-6500 x 124
Fax: 352-335-6506

1 patch for repository http://common-lisp.net/project/iterate/darcs/iterate:

Tue May  8 14:51:07 EDT 2012  Russ Tyndall <russ <at> acceleration.net>
  * added a restart to remove conflicting clauses

New patches:

[added a restart to remove conflicting clauses
Russ Tyndall <russ <at> acceleration.net>**20120508185107
 Ignore-this: b7c4c6eec565dd435b8e9e5403fcb0a8
] {
hunk ./iterate.lisp 1322
 	    (kw2 (clause-info-keywords ci2)))
 	(if (= insert-n 2)
 	    (rotatef kw1 kw2))
-	(error "Iterate: Inserting clause ~a would create ~
+	(restart-case
+            (error "Iterate: Inserting clause ~a would create ~
   an ambiguity with clause ~a"
hunk ./iterate.lisp 1325
-	       kw1 kw2))))
+                   kw1 kw2)
+          (delete-conflict ()
+            :report "Delete the original clause"
+            (remove-clause kw2))))))

 
 (defun ambiguous-clauses? (ci1 ci2)
}

Context:

[fix package nickname in case sensitive mode
attila.lendvai <at> gmail.com**20110927152614
 Ignore-this: fb1ba1d418b4a20a0cd4e697d943a0e6
] 
[move list-of-forms? out of the #L eval-when, because it's also used by other parts of iterate
attila.lendvai <at> gmail.com**20110119161133
 Ignore-this: 97545988c4a3eab02434f222120b1a1
] 
[added bug/walk.2
attila.lendvai <at> gmail.com**20100603093335
 Ignore-this: faa1bd48d0450e76652552bb47bcff02
] 
[first-time-p bugfix: return-code :body must return list of forms
Joerg-Cyril Hoehle <hoehle <at> 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 <at> users.sourceforge.net>**20070525081443] 
[Use  <at> :,  <at> . and two spaces between sentences
Joerg-Cyril Hoehle <hoehle <at> 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 <at> users.sourceforge.net>**20070525074338] 
[Renamed back to sharpL-reader
attila.lendvai <at> gmail.com**20070506100744] 
[Fix sharpL reader, add :execute to the eval-when to make (load "iterate" :compiling t) work on clisp
attila.lendvai <at> gmail.com**20070506100704] 
[Convert manual to Texinfo.
Luis Oliveira <loliveira <at> common-lisp.net>**20060713142915] 
[make FOR...IN/ON with dotted lists work like LOOP
hoehle <at> 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 <at> users.sourceforge.net>**20070503095309] 
[walk-tagbody must not macroexpand symbol/tags among its statements
Joerg-Cyril Hoehle <hoehle <at> users.sourceforge.net>**20070404124132] 
[add ELSE test cases, remove GNU Arch tag
Joerg-Cyril Hoehle <hoehle <at> users.sourceforge.net>**20070503093008] 
[Clean up #L stuff, do not leave #L enabled after loading iterate
attila.lendvai <at> 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 <at> gmail.com**20070215151652] 
[wrap code in progns, to avoid possiblity of multiple nil tags in tagbody
 Henrik Hjelte <henrik <at> evahjelte.com>**20061025145324] 
[test to detect bug, more than one nil tag in tagbody
 Henrik Hjelte <henrik <at> evahjelte.com>**20061025145128] 
[Added release.sh
attila.lendvai <at> gmail.com**20060506155953] 
[TAG 1.4.3
attila.lendvai <at> gmail.com**20060505134701] 
Patch bundle hash:
b69e87f03a598d024f7e1693f4fca6ce749db740
1 patch for repository http://common-lisp.net/project/iterate/darcs/iterate:

Tue May  8 14:51:07 EDT 2012  Russ Tyndall <russ <at> acceleration.net>
  * added a restart to remove conflicting clauses

New patches:

[added a restart to remove conflicting clauses
Russ Tyndall <russ <at> acceleration.net>**20120508185107
 Ignore-this: b7c4c6eec565dd435b8e9e5403fcb0a8
] {
hunk ./iterate.lisp 1322
 	    (kw2 (clause-info-keywords ci2)))
 	(if (= insert-n 2)
 	    (rotatef kw1 kw2))
-	(error "Iterate: Inserting clause ~a would create ~
+	(restart-case
+            (error "Iterate: Inserting clause ~a would create ~
   an ambiguity with clause ~a"
hunk ./iterate.lisp 1325
-	       kw1 kw2))))
+                   kw1 kw2)
+          (delete-conflict ()
+            :report "Delete the original clause"
+            (remove-clause kw2))))))

 
 (defun ambiguous-clauses? (ci1 ci2)
}

Context:

[fix package nickname in case sensitive mode
attila.lendvai <at> gmail.com**20110927152614
 Ignore-this: fb1ba1d418b4a20a0cd4e697d943a0e6
] 
[move list-of-forms? out of the #L eval-when, because it's also used by other parts of iterate
attila.lendvai <at> gmail.com**20110119161133
 Ignore-this: 97545988c4a3eab02434f222120b1a1
] 
[added bug/walk.2
attila.lendvai <at> gmail.com**20100603093335
 Ignore-this: faa1bd48d0450e76652552bb47bcff02
] 
[first-time-p bugfix: return-code :body must return list of forms
Joerg-Cyril Hoehle <hoehle <at> 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 <at> users.sourceforge.net>**20070525081443] 
[Use  <at> :,  <at> . and two spaces between sentences
Joerg-Cyril Hoehle <hoehle <at> 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 <at> users.sourceforge.net>**20070525074338] 
[Renamed back to sharpL-reader
attila.lendvai <at> gmail.com**20070506100744] 
[Fix sharpL reader, add :execute to the eval-when to make (load "iterate" :compiling t) work on clisp
attila.lendvai <at> gmail.com**20070506100704] 
[Convert manual to Texinfo.
Luis Oliveira <loliveira <at> common-lisp.net>**20060713142915] 
[make FOR...IN/ON with dotted lists work like LOOP
hoehle <at> 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 <at> users.sourceforge.net>**20070503095309] 
[walk-tagbody must not macroexpand symbol/tags among its statements
Joerg-Cyril Hoehle <hoehle <at> users.sourceforge.net>**20070404124132] 
[add ELSE test cases, remove GNU Arch tag
Joerg-Cyril Hoehle <hoehle <at> users.sourceforge.net>**20070503093008] 
[Clean up #L stuff, do not leave #L enabled after loading iterate
attila.lendvai <at> 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 <at> gmail.com**20070215151652] 
[wrap code in progns, to avoid possiblity of multiple nil tags in tagbody
 Henrik Hjelte <henrik <at> evahjelte.com>**20061025145324] 
[test to detect bug, more than one nil tag in tagbody
 Henrik Hjelte <henrik <at> evahjelte.com>**20061025145128] 
[Added release.sh
attila.lendvai <at> gmail.com**20060506155953] 
[TAG 1.4.3
attila.lendvai <at> gmail.com**20060505134701] 
Patch bundle hash:
b69e87f03a598d024f7e1693f4fca6ce749db740
psexton.2a | 13 Dec 01:35 2012
Picon

Bug with (collect :at :beginning)

When collecting values into a list, if the first value collected uses (collect val :at :beginning),
and a subsequent value does not use the ":at :beginning" clause, then an error will occur: 
"The value nil is not of type cons".

The following reproduces this error:

(iterate
 (for i from 1 to 10)
 (if (oddp i)
     (collect i :at :beginning)
     (collect i)))

Denis Budyak | 23 Oct 01:05 2012
Picon

Fwd: using keywords in clauses

Second reply to Zach which should have been sent to an iterate-devel
mailing list too.

---------- Forwarded message ----------
From: Denis Budyak <budden73 <at> gmail.com>
Date: Tue, 16 Oct 2012 22:15:18 +0400
Subject: Re: [iterate-devel] using keywords in clauses
To: Zach <zach.smith <at> colorado.edu>

Zach, list,
> Why isn't your patch
>nothing more than a single file that looks like:
>(iterate:defsynonym :for iterate:for)
>(iterate:defsynonym :collect iterate:collect)
>...
>(iterate:defsynonym :appending iterate:appending)
>Why isn't this just a small separate library called iterate-keyword
>that only exports ITERATE?
This is because synonym mechanism is not universal. It doesn't cover
cases of iterate:first-time-p, iterate:next-iteration etc. defsynonym
simply do not work for them. To make them work, one need to patch
iterate itself.

> One last thing, I would hope that you wouldn't actually attempt to
> patch iterate to not export FOR, WHILE
Of course I didn't attempt this. In fact, there is no need to use iterate
in any package, if one can use keywords. Just writing
(:import-from :iter #:iter)
would suffice.

>  Is the root of your desire to do this the
>fact that you want to use the symbols FOR, WHILE, COLLECT, etc in the
>same package that you want to use Iterate?
Iterate is a very agressive exporter of symbols :) When I started
using iterate,
I just tried to :use both :iterate and :cl-utilities and this gave me
a conflict.
One can easily imagine an applicaion (e.g. language parser) where
symbols like FOR and WHILE are treated as data and it is desirable
for them to come from specific package, not from iterate.

Some other person is likely to implement simplified "while" loop. Third
person might just try playing with iterate, and she will get conflict
in the following innocent lisp session:

; Hallo from your lisp
%(in-package :cl-user)
%(use-package :iterate)
... conflict ...
as FOR might be exported into :cl-user from loop during initialization.

> but it would also break any body's code that decided to
> (defmacro-clause :for ...)
Yes, and it is expected, but sometimes breaking changes occur
in a software.
>  (defun :go ...)
defsynonym is not a defun, it only puts a property on a symbol,
so the symbol does not change its meaning outside of iterate construct.

Just because I agree one should not normally (defun :for),
I believe that change proposed is not very harmful as it can be hardly
expected that it would break anyone's code.

If it is considered a serious threat, we could define *features* member
so that iterate could be bulid either with or without keywords support.
Unfortunately it seem to be impossible to enable keywords support
via a separate library.

Regards, Budden

Denis Budyak | 23 Oct 01:04 2012
Picon

Fwd: using keywords in clauses, reply 1

Hi list!
  I see I didn't send my reply to Zach into a iterate-devel mailing
list, by omission. I think now it is the time to correct that.

---------- Forwarded message ----------
From: Denis Budyak <budden73 <at> gmail.com>
Date: Tue, 16 Oct 2012 11:06:34 +0400
Subject: Re: [iterate-devel] using keywords in clauses
To: Zach <zach.smith <at> colorado.edu>

Hi Zach, list!
> If you encode FOR and COLLECT as special tokens that Iterate's
> parser/compiler just understands you break the extensibility.
Iterate-keywords makes minimal change to iterate. Roughly, it makes
(defsynonym :any-clause-head any-clause-head), but only for
standard iterate clauses, not for user defined. As synonyms do not
work with special clauses like (next-iteration) (it can be considered a
bug in synonym mechanism), patch to iterate itself was required.

Consequently, it does not break your example.
%(iterate-keywors:iter (test:for i in-whole-vector #(1 3)) (:collect i))
(1 3)

%(iterate-keywors:iter (:for i in-whole-vector #(1 3)) (:collect i))
...errs...

For is intended to be extensible via second keyword, in-whole-vector
in our case. If we define it as in manual,
%(in-package :iterate-keywords)
%(defmacro-clause (FOR var IN-WHOLE-VECTOR v) ...),
It will work with iterate-keywords as intended:
%(in-package:cl-user)
%(iterate-keywords:iter (:for i in-whole-vector #(1 3)) (:collect i))
(1 3)
If we define any new clause, iterate-keywords won't touch it.
We can define it in :test package and use the symbol
from that package, that is,
%(iter (test:our-clause))
Additionally, we can make
%(defsynonym :our-clause test:our-clause)
and thus enable ourselves to use keyword:
%(iter (:our-clause))

> and even then, it would suffer from name collisions inherent in the keyword package
Most of iterate keywords are in a keyword package already as they are
used in common lisp loop macro. What kind of collision do you mean?

Zach | 16 Oct 22:26 2012
Picon

Re: using keywords in clauses

Budden,

Like I said, I think we have passed the level of "break someone's
(reasonable) code" and is more in the realm of "a matter of taste".
It is true that iterate exports many symbols and I believe that I have
a vague memory that this was an annoyance long ago, so it might be a
hurdle for new users.  You in effect have convinced me that it won't
be detrimental to me or any hypothetical user I can think of (other
than those people that are doing a (defclause :for ...) and they
deserve what they get).  If the description I gave of the new
functionality is accurate, the only issues I still have are:

1. This will discourage new users/developers from writing their own
extensions to Iterate, as they will think there is something special
about the symbols :FOR, :WHILE, :WITH, etc (and they are special, in
that the user cannot write their own just like them).

2. It will make the extensions that are written a little odd looking
as they don't keep with the general interface of the abstraction.

3. Given 1 and 2, someone might wonder in the future why there isn't a
way to define your own keyword style iterate construct.  If this
happens we are in the odd position where there are two nearly
independent methods of extension in Iterate (both of which is, of
course, in addition to the clause overloading that you can do by using
DEFCLAUSE with other "keyword specialization" (like the
in-whole-vector example in the manual)).  As I discussed, one of these
methods of extending Iterate is inherently weaker than the other due
to name collisions introduced by you.  This seems like a real mess to
be avoided.

These are all social problems, however, not technical.  Iterate is
something I very much enjoy using and would dislike it if, due to
these social problems, extensibility is either weakened, turning
Iterate into merely Loop with parentheses, or bifurcated such that
extending Iterate is a mess (but a working mess).  Of the two, I can
deal with messy, inconsistent code.

On the idea of backwards compatibility, I would say your change is
basically backward compatible and don't worry about *FEATURES*.  I
would suggest you provide a new package ITERATE-KEYWORDS that only
exports ITER and ITERATE but keep the ITERATE package exports the
same.  Just my opinion and I think this is what you already intend to
do.

As to the matter of taste, you argue that this is annoying to use the
Iterate package as other packages define and export the symbols FOR or
WHILE.  This is true across all of Common Lisp and we have ways of
dealing with it (i.e. shadowing, giving the full package qualified
name).  It is certainly annoying when it comes up, but I think you
wouldn't argue that we should remedy package collisions by interning
one package's exported symbols to some other unrelated package (say
the keyword package) and modify the Lisp eval function to map those
references to the correct package.  Other than the fact that with
Iterate we have the means to modify the Lisp eval function portably
and safely (a macro environment) I'm not sure I see how this is very
different.  So, I'm not sure this is "the right thing to do," but I am
also sympathetic to the fact that symbol name collisions can be
irritating when you want to use multiple packages.

In case it is not entirely clear, I am not the Iterate maintainer, nor
a developer on the Iterate project at all.  I am just writing this as
a party with a vested interest.  The silence of the maintainer is a
bit troublesome, though.

Zach

On Tue, Oct 16, 2012 at 12:15 PM, Denis Budyak <budden73 <at> gmail.com> wrote:
> Zach, list,
>> Why isn't your patch
>>nothing more than a single file that looks like:
>>(iterate:defsynonym :for iterate:for)
>>(iterate:defsynonym :collect iterate:collect)
>>...
>>(iterate:defsynonym :appending iterate:appending)
>>Why isn't this just a small separate library called iterate-keyword
>>that only exports ITERATE?
> This is because synonym mechanism is not universal. It doesn't cover
> cases of iterate:first-time-p, iterate:next-iteration etc. defsynonym
> simply do not work for them. To make them work, one need to patch
> iterate itself.
>
>> One last thing, I would hope that you wouldn't actually attempt to
>> patch iterate to not export FOR, WHILE
> Of course I didn't attempt this. In fact, there is no need to use iterate
> in any package, if one can use keywords. Just writing
> (:import-from :iter #:iter)
> would suffice.
>
>>  Is the root of your desire to do this the
>>fact that you want to use the symbols FOR, WHILE, COLLECT, etc in the
>>same package that you want to use Iterate?
> Iterate is a very agressive exporter of symbols :) When I started
> using iterate,
> I just tried to :use both :iterate and :cl-utilities and this gave me
> a conflict.
> One can easily imagine an applicaion (e.g. language parser) where
> symbols like FOR and WHILE are treated as data and it is desirable
> for them to come from specific package, not from iterate.
>
> Some other person is likely to implement simplified "while" loop. Third
> person might just try playing with iterate, and she will get conflict
> in the following innocent lisp session:
>
> ; Hallo from your lisp
> %(in-package :cl-user)
> %(use-package :iterate)
> ... conflict ...
> as FOR might be exported into :cl-user from loop during initialization.
>
>> but it would also break any body's code that decided to
>> (defmacro-clause :for ...)
> Yes, and it is expected, but sometimes breaking changes occur
> in a software.
>>  (defun :go ...)
> defsynonym is not a defun, it only puts a property on a symbol,
> so the symbol does not change its meaning outside of iterate construct.
>
> Just because I agree one should not normally (defun :for),
> I believe that change proposed is not very harmful as it can be hardly
> expected that it would break anyone's code.
>
> If it is considered a serious threat, we could define *features* member
> so that iterate could be bulid either with or without keywords support.
> Unfortunately it seem to be impossible to enable keywords support
> via a separate library.
>
> Regards, Budden

Zach | 16 Oct 15:08 2012
Picon

Re: using keywords in clauses

Denis,

I got to thinking after I sent the last email and realized that my
example was a bit confusing, but you did an excellent job deciphering
it.  To sum up what it seems you are proposing:

Symbols in the iterate package like FOR, WHILE, COLLECT, APPENDING,
will be blessed in such a way that they can be accessed via symbols in
the keyword package.  Writing extensions to Iterate via
defmacro-clause and friends will remain the same, it will take a
symbol, not a keyword, and will not try to institute the same keyword
short cut as the blessed clauses.

Is that a fair description?  Is the root of your desire to do this the
fact that you want to use the symbols FOR, WHILE, COLLECT, etc in the
same package that you want to use Iterate?

As for your points, I will work backwards:

> Most of iterate keywords are in a keyword package already as they are
> used in common lisp loop macro. What kind of collision do you mean?

People don't usually worry about keyword collisions because keywords
act as syntactic markers and do not hold bindings.  I am reminded of a
recent post by Xach regarding binding certain functions to keywords in
your .rc file like...

(defun :go (&optional (thing *))
  "View THING with some appropriate viewer."
  ;; On my Mac laptop, I use "open" instead.
  (sb-ext:run-program "gnome-open" (list (princ-to-string thing))
                      :search t)
  thing)

These are functions that serve to make the Lisp environment a bit more
appealing, not to extend a program's capabilities.  This is a fine
thing to do right up until the point that someone decides to add these
definitions to some utility library.  Once that happens, loading that
library will clobber any definitions that were in place before.  This
is an example of how the keyword package is prone to collisions.  The
collision above is in the space of function definitions, but in
Iterate we have a similar space of clauses.  Currently those clauses
are represented as symbols which afford us all of the protections that
the package system gives us to avoid those kinds of collisions.

Probably the most confusing thing that my last message did was use the
code in the manual dedicated to extending FOR.  This made it seem like
I was proposing a means that we could extend FOR while I was talking
about working within the framework Iterate defines to build a
different kind of clause that happens to be named TEST:FOR.  Let's
say, as a better example, I wanted to define that in my package, that
happens to use some data structure that indexes for 1 instead of 0,
for loops in iterate are to always default to starting index 1 rather
than 0.  One way to do this is to define my own clause, FOR that is
local to the package and has the exact definition as ITERATE:FOR
except that that initial default 0 is turned into a 1.  Now I'm not
saying that I would ever do this, I'm not saying that this is a good
idea, I'm not even saying (now that I see what you are proposing) that
I cannot do this with your proposed change in place, but I am saying
that the way Iterate is currently set up, INDEX-FROM-ONE:FOR would be
on equal syntactic footing as ITERATE:FOR.  I do feel that this is an
extremely clean mechanism that holds a lot of similarity with standard
CL functionality.

And with that, I will walk back my objection from, "it might break
stuff" to "it isn't necessary and it doesn't look consistent".  So I
suppose that it is a matter of taste.  However, as you pointed out,
but I was unaware of, Iterate has defsynonym.  Why isn't your patch
nothing more than a single file that looks like:

(iterate:defsynonym :for iterate:for)
(iterate:defsynonym :collect iterate:collect)
...
(iterate:defsynonym :appending iterate:appending)

Why isn't this just a small separate library called iterate-keyword
that only exports ITERATE?

Note that including this in Iterate distribution would enable usage of
keywords as an alternate syntax for those clauses, drivers, and
collectors that happen to have been blessed by Iterate during its
creation, but it would also break any body's code that decided to
(defmacro-clause :for ...).  I'm not sure that this is worth worrying
about, but from my point of view this is wrong in the same way someone
defining a library that has (defun :go ...) in it is wrong.

One last thing, I would hope that you wouldn't actually attempt to
patch iterate to not export FOR, WHILE, etc as that really would break
code.

Zach

On Tue, Oct 16, 2012 at 1:06 AM, Denis Budyak <budden73 <at> gmail.com> wrote:
> Hi Zach, list!
>> If you encode FOR and COLLECT as special tokens that Iterate's
>> parser/compiler just understands you break the extensibility.
> Iterate-keywords makes minimal change to iterate. Roughly, it makes
> (defsynonym :any-clause-head any-clause-head), but only for
> standard iterate clauses, not for user defined. As synonyms do not
> work with special clauses like (next-iteration) (it can be considered a
> bug in synonym mechanism), patch to iterate itself was required.
>
> Consequently, it does not break your example.
> %(iterate-keywors:iter (test:for i in-whole-vector #(1 3)) (:collect i))
> (1 3)
>
> %(iterate-keywors:iter (:for i in-whole-vector #(1 3)) (:collect i))
> ...errs...
>
> For is intended to be extensible via second keyword, in-whole-vector
> in our case. If we define it as in manual,
> %(in-package :iterate-keywords)
> %(defmacro-clause (FOR var IN-WHOLE-VECTOR v) ...),
> It will work with iterate-keywords as intended:
> %(in-package:cl-user)
> %(iterate-keywords:iter (:for i in-whole-vector #(1 3)) (:collect i))
> (1 3)
> If we define any new clause, iterate-keywords won't touch it.
> We can define it in :test package and use the symbol
> from that package, that is,
> %(iter (test:our-clause))
> Additionally, we can make
> %(defsynonym :our-clause test:our-clause)
> and thus enable ourselves to use keyword:
> %(iter (:our-clause))
>
>> and even then, it would suffer from name collisions inherent in the keyword package
> Most of iterate keywords are in a keyword package already as they are
> used in common lisp loop macro. What kind of collision do you mean?

Denis Budyak | 14 Oct 13:58 2012
Picon

using keywords in clauses

Hi list! Some time ago I've suggested that one can use keywords in clauses, e.g.
(iter (:for i :from 1 to 10))
instead of
(iter (for i from 1 to 10))
This way, one have to import just one symbol iter:iter into her package
to use iterate.
I made a patch and sent it to this mailing list, but it didn't pass through,
maybe due to size limitations or by some other reason.
After that, I created a fork,
http://sourceforge.net/projects/iteratekeywords/
but several commits were made to iterate since that and my code seem
to be outdated.
I suggest re-doing my changes so that they could be merged into main
iterate repository.
But before doing that I'd like to see explicit confirmation that my
changes will be accepted (patch is very big and contains about hundred
of changes).

Anton Vodonosov | 7 May 00:35 2012
Picon

iterate tests regression on ACL linux 64 (quicklisp 2012-04-07 vs 2012-03-07): handler-bind.1

Iterate test suite shows regression between quicklisp 2012-03-07 and  quicklisp 2012-04-07.

acl-8.2a-linux-x64.

Test logs:

quicklisp 2012-03-07: 
http://cl-test-grid.appspot.com/blob?key=AMIfv97pKvcGKmd6_yqeRupJ3ii6PsLmOuUZ0zDuQzUuJQgi_7uJX43ujwQLaaqlRBwTLkipZNoOijXq1ORRPH5fXepLeh-qO0a9Y1O6u1lEOnvDxgKYWuRnS2BWJQqPnRuvsf4xJ5KPwByJXBgamPqGXmoL413eHg
failed tests: bug/walk.2 code-movement.else code-movement.finally code-movement.finally-protected

quicklisp 2012-04-07: 
http://cl-test-grid.appspot.com/blob?key=20006
failed tests: bug/walk.2 code-movement.else code-movement.finally
code-movement.finally-protected handler-bind.1

As you see, new failure is handler-bind.1.

Anton Vodonosov | 7 May 00:39 2012
Picon

iterate tests regression on SBCL 1.0.54 (quicklisp 2012-04-07 vs 2012-03-07): handler-bind.1

Iterate test suite shows regression between quicklisp 2012-03-07 and  quicklisp 2012-04-07.

sbcl-1.0.54.84.mswinmt.1137-215bdc8-win-x64.

Test logs:

quicklisp 2012-03-07:
http://cl-test-grid.appspot.com/blob?key=AMIfv94-RAJv0FSm0WjXUTgYha9U7tUSAzwo4V3HxonJSNx5TPSEwRcW2ca7clAc5pJIh5JZjhMS7GZWQih7hViiC7OmZfY1onNIBciD7m6kbVJu9FeiRgeGEtwrPd4YxXx-dB-y6UPs8LFQN5_-st7G9ICpZVRLkA
failed tests: NONE

quicklisp 2012-04-07:
http://cl-test-grid.appspot.com/blob?key=53022
failed tests: bug/walk.2

As you see, new failure is bug/walk.2.


Gmane