Some other question comes to mind: does the need justify a new construct, or are the present ones "good enough"? I.e. if-first-iteration (non-sharing) could also be done using (for first-iteration initially t then nil)

Well, to be honest i didn't know about the possibility of the above expression. I think it may even invalidate first-iteration-p... but still i think you need it often enough that having some frequently used constructs out of the box may be worth it.

Of course, that would not share variables, but in DSL terms, it looks like a growth of non-orthogonal features, with slight variations between each (e.g. yours shares variables, if-first-time allows non-top-level use, if initially then is not as efficient (who cares?) etc.)

Well, technically your above initially-then solution is the same as first-iteration-p would be, it just needs an extra line of user code. But on the other hand you are right: if we add first-iteration-p, then why don't we add x, y, and z...

My take is: if a feature makes the user code smaller and is obvious enough then i think it's worth adding it, even if it's not orthogonal. But if it needs a long documentation about possible interferences/etc then it's not worh adding it.

...

(finally (return `(progn ,@it)))

Why not just `(progn .,(iter #)) ; read . , if you prefer -- it's not ,. or `(progn ,@(iter #)) since the "final" clause it never conditional?

I couldn't make them work, so i assume these are alternative syntax ideas, but then I prefer "it"... (please note the quotes :)

thanks for the ideas,

- attila