![](https://secure.gravatar.com/avatar/2f7ec3b37425cf4e077e7ef376e451be.jpg?s=120&d=mm&r=g)
Marc Battyani wrote:
Plans for 1.5: + Move more code from the initially / loop prologue section inside the let binding initialization, which might cause some user code to fail because of code movement
Please don't wreck that! It's the reason I initially started to use iterate. Those parts (prologue/epilog/var bindings) are under (and badly) specified in LOOP and implementations differ on this. So let's keep it in a sane way.
What I mean is that Iterate is inconsistent. Did you know that WITH clauses get completely placed inside the surrouding let, while FOR ... ON <list> gets set in the :initially section, while other (e.g. reducing ...) also get set inside LET? I wanted to move as much as possible inside the surrouding LET. There's a *small* posibility that user code will break. In fact, I expect none of the current tests to fails as a result of such a change.
For a farther future: move to another design for iteration Do you already have some ideas on this ? No. gclcvs (which passed most Iterate tests) reminded me of the other Iterate package featuring gathering. I'll look at that.
What really disturbs me with Iterate has a design weakness about referential transparency and inadvertent capture, e.g. (iter (with-some-other-macro (collect foo))) when with-some-other-macro itself expands to an iterate loop. It similar to those cases when an implicit block would change the target of a return statement. There's IMHO no way around that deficiency in Iterate. LOOP OTOH is robust against that, since it knows no clauses nested inside normal Lisp forms. Regards, Jörg.