[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