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

[Iterate-devel] iterate on list bug?
by Gábor Balázs 21 May '14

21 May '14

hY, I have a feeling this is a bug. (defvar mylist '(:one :two :three)) (iter (for var on mylist) (collect (car var) into result) (finally (return (values result var)))) (:ONE :TWO :THREE) (:THREE) I think var should be empty at the end, so the result would match the result of loop as (loop for var on mylist collect (car var) into result finally (return (values result var))) (:ONE :TWO :THREE) NIL The problem is caused by the end test code location. The bold lines should appear in reverse order, I think. (macroexpand-1 '(iter (for var on mylist) (collect (car var) into result) (finally (return (values result var))))) (LET* ((#:LIST214 NIL) (VAR NIL) (RESULT NIL) (#:END-POINTER215 NIL) (#:TEMP216 NIL)) (BLOCK NIL (TAGBODY (PROGN (SETQ #:LIST214 MYLIST)) LOOP-TOP-NIL (PROGN * (IF (ATOM #:LIST214) (GO LOOP-END-NIL)) (SETQ VAR #:LIST214)* (SETQ #:LIST214 (CDR #:LIST214)) (PROGN (SETQ #:TEMP216 (LIST (CAR VAR))) (SETQ #:END-POINTER215 (IF RESULT (SETF (CDR #:END-POINTER215) #:TEMP216) (SETQ RESULT #:TEMP216))) RESULT)) (PROGN) (GO LOOP-TOP-NIL) LOOP-END-NIL (PROGN (RETURN (VALUES RESULT VAR)))) NIL)) Best, ` bg`

3 4

Re: [Iterate-devel] [Sbcl-devel] pprinter regression
by Attila Lendvai 23 Apr '14

23 Apr '14

(i'm CC'ing this mail to iterate-devel to notify people there also. please only reply-all to this mail if you intend to send your reply to iterate-devel also.) On Wed, Apr 23, 2014 at 8:02 AM, Douglas Katzman <dougk(a)google.com> wrote: > Attached is a patch for 'iterate'. Hopefully someone on this list can patch > that it. thanks, i've pushed the patch into the official iterate repo. Wed Apr 23 10:47:59 ALMT 2014 Douglas Katzman <dougk(a)google.com> * make the #L reader macro standard conformant by not assuming anything about the representation of quasiquoted forms. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Being really good at C++ is like being really good at using rocks to sharpen sticks.” — Thant Tessman

1 0

[iterate-devel] small feature request w/ patch
by Ryan Davis 04 Jan '13

04 Jan '13

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

2 1

[iterate-devel] Bug with (collect :at :beginning)
by psexton.2a＠gmail.com 13 Dec '12

13 Dec '12

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)))

1 0

[iterate-devel] Fwd: using keywords in clauses
by Denis Budyak 22 Oct '12

22 Oct '12

Second reply to Zach which should have been sent to an iterate-devel mailing list too. ---------- Forwarded message ---------- From: Denis Budyak <budden73(a)gmail.com> Date: Tue, 16 Oct 2012 22:15:18 +0400 Subject: Re: [iterate-devel] using keywords in clauses To: Zach <zach.smith(a)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

1 0

[iterate-devel] Fwd: using keywords in clauses, reply 1
by Denis Budyak 22 Oct '12

22 Oct '12

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(a)gmail.com> Date: Tue, 16 Oct 2012 11:06:34 +0400 Subject: Re: [iterate-devel] using keywords in clauses To: Zach <zach.smith(a)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?

1 0

Re: [iterate-devel] using keywords in clauses
by Zach 21 Oct '12

21 Oct '12

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(a)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?

2 2

Re: [iterate-devel] using keywords in clauses
by Zach 16 Oct '12

16 Oct '12

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(a)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

1 0

[iterate-devel] using keywords in clauses
by Denis Budyak 14 Oct '12

14 Oct '12

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).

2 1

[iterate-devel] iterate tests regression on SBCL 1.0.54 (quicklisp 2012-04-07 vs 2012-03-07): handler-bind.1
by Anton Vodonosov 11 May '12

11 May '12

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-RAJv0FSm0WjXUTgYha9U7tUSAz… 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.

4 8