"Hoehle, Joerg-Cyril" Joerg-Cyril.Hoehle@t-systems.com writes:

Hi Jorg,

here's how I see the next steps w.r.t. Iterate.

I've already sent a version of Iterate 1.4 to some of you (and it's on common-lisp.net thanks to Marco).

I want 1.4 to be the last really compatibly-conservative Iterate around, before I'll make some possibly incompatible changes in 1.5.

Plans for minor updates to 1.4:

• some more bug fixes (e.g. did you know that in-stream did not work

correctly with destructuring)?

-- some already done (but not yet sent to you).

Good

• most important: additions to the documentation:

• a glossary (what's the loop epilogue anyway?)
• a reference of which clause is allowed at top-level only, as a

generator etc.

Good

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.

• harmonize "clause identifiers" across defmacro-driver, remove-clause and

display-iterate-clause

• possible change to thereis (different interaction with other clauses

like always etc.)

OK

Somewhere in between:

• other minor modifications (e.g. avoid duplication of code in some

clauses)

• deprecate add-loop-body-wrapper (a misnomer) and export

add-iterate-wrapper or wrap-iterate-form or wrap-iterate-with wrap-iterate-using -- what do you suggest?

• numerous other topics I have on my list

OK also.

For a farther future: move to another design for iteration that does not need a code-walker and as such suffers from the problematic of pre-order code traversal, or consider using a portable code walker library or implementation-dependent code.

Do you already have some ideas on this ?

Cheers,

Marc