Ryan Davis | 2 Jan 21:50 2013

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

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
<       (error "Iterate: Inserting clause ~a would create ~
>       (restart-case
>             (error "Iterate: Inserting clause ~a would create ~
<              kw1 kw2))))
>                    kw1 kw2)
>           (delete-conflict ()
>             :report "Delete the original clause"
>             (remove-clause kw2))))))



(Continue reading)

psexton.2a | 13 Dec 01:35 2012

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:

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

Denis Budyak | 23 Oct 01:05 2012

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.

(Continue reading)

Denis Budyak | 23 Oct 01:04 2012

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

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) ...),
(Continue reading)

Zach | 16 Oct 22:26 2012

Re: using keywords in clauses


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.
(Continue reading)

Zach | 16 Oct 15:08 2012

Re: using keywords in clauses


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.
(Continue reading)

Denis Budyak | 14 Oct 13:58 2012

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

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.


Test logs:

quicklisp 2012-03-07: 
failed tests: bug/walk.2 code-movement.else code-movement.finally code-movement.finally-protected

quicklisp 2012-04-07: 
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

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.


Test logs:

quicklisp 2012-03-07:
failed tests: NONE

quicklisp 2012-04-07:
failed tests: bug/walk.2

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

Ilya Perminov | 28 Mar 00:49 2012

Bug: "collect at beginning" ignores specified sequence type


I reported this bug a few years ago, but it is still there.
If both AT BEGINNING and RESULT-TYPE are specified, RESULT-TYPE is ignored.
(iter (for i below 2) (collect i at beginning result-type vector))
returns (1 0).

Can someone with write access to the darcs repository fix the bug
please. My previous report includes a patch:
http://www.mail-archive.com/iterate-devel <at> common-lisp.net/msg00142.html


Marco Antoniotti | 1 Feb 14:13 2012

ELS 2012, Zadar, Croatia

Apologies for the multiple postings. 


European Lisp Symposium 2012, Zadar, Croatia, April 30th - May 1st, 2012 


The purpose of the European Lisp Symposium is to provide a forum for 
the discussion and dissemination of all aspects of design, 
implementation and application of any of the Lisp and Lisp-inspired 
dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, 
Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, and so on. We 
encourage everyone interested in Lisp to participate. 

The main theme of the 2012 European Lisp Conference is 
"Interoperability: Systems, Libraries, Workflows".  Lisp based and 
functional-languages based systems have grown a variety of solutions 
to become more and more integrated with the wider world of Information 
and Communication Technologies in current use.  There are several 
dimensions to the scope of the solutions proposed, ranging from 
"embedding" of interpreters in C-based systems, to the development of 
abstractions levels that facilitate the expression of complex context 
dependent tasks, to the construction of exchange formats handling 
libraries, to the construction of theorem-provers for the "Semantic 
Web".  The European Lisp Symposium 2012 solicits the submission of 
papers with this specific theme in mind, alongside the more 
traditional tracks which have appeared in the past editions. 

We invite submissions in the following forms: 
(Continue reading)