[iterate-devel] Version plan for Iterate 1.4 and 1.5
Marc Battyani
marc.battyani at fractalconcept.com
Thu Jun 2 14:27:59 UTC 2005
"Hoehle, Joerg-Cyril" <Joerg-Cyril.Hoehle at 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
More information about the iterate-devel
mailing list