[iterate-devel] Fwd: if-first-iteration, a little better vers ion as an arch patch

Attila Lendvai attila.lendvai at gmail.com
Wed Jan 11 20:44:07 UTC 2006


> 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 , at 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



More information about the iterate-devel mailing list