[iterate-devel] iterate critique I -- semantics may depend on macroexpansion

[Hoehle, Joerg-Cyril]

Hi,

while we are at limitations of Iterate due to the need for code-walking, isn't there some inherent limitation in the attempt to yield varying expansion forms depending on some part deep inside the body?

Consider
(iterate
 (when nil (collect 1 into x))
 (repeat 3)
 (finally (return x))

Some user- or implementation-supplied macros may do some primitive value analysis and macroexpand a complete macro form to NIL, 'NIL or (PROGN).

For example, the WHEN form above may expand to (PROGN) due to an explicit test for NIL, Iterate would then never see the COLLECT INTO, therefore not produce a binding for X, yielding different semantics to the whole example (X as a free variable).

While concretely, I wouldn' expect WHEN to do this, I've seen other macros do this simple kind of optimization, instead of leaving it to the compiler. E.g. Iterate itself contains some constant-folding code.

I have no idea how to avoid this situation. LOOP avoids it because it doesn't need a code-walker.

Is that a sign of poor design when the intent is a general-purpose library utility?

I've tried to think of a variant of Iterate which would require more to be declared in its top-level (e.g. require WITH clauses), while still allowing deeply nested COLLECT expressions etc., but my thoughts have made like no progress in this area.

What do you think about such issues?

Regards,
	Jorg Hohle.