I am glad to see that plt is considering including some comprehension macros.&nbsp; I realize that they are not yet final, but I have some comments.<br><br>A) The behavior of in-range seems to have been inherited from srfi-42 and python.&nbsp; In my opinion it is one of the few things that python gets wrong.&nbsp; If you assign problems 7 through 9 as homework to your students, do you really expect them to hand back just problems 7 and 8?&nbsp; (These would be abstract ideal students.)
<br><br>B) The behavior of #:when in a parallel for loop scares me.&nbsp; I would prefer that either<br>1) The #:when constructs always behaved as if they occurred at the end of the list of generators.<br>or<br>2) The #:when construct is illegal anywhere except at the end of a parallel list of generators.
<br><br>I agree that something that splits a parallel &#39;for&#39; construct up into nested pieces is useful, I just don&#39;t think that overloading #:when is the right way to do it. &nbsp; I know for certain that I will screw it up. Until they start making bulletproof tevas please don&#39;t make it so easy for me to shoot myself in the foot.
<br><br>C) What is the difference between the fourth and sixth parameter to make-do-sequence? Why are they both necessary?<br><br>D)&nbsp; A &#39;for*/seq&#39;&nbsp; form that takes a set of nested sequences and returns a generator for all the values of the nested would be useful.&nbsp; I&#39;ve been trying to get one integrated into Jens&#39; srfi-42 rewrite using William Farr&#39;s multiple value yield, but my macro skills are not yet up to the task. 
<br><br>E)&nbsp; The begin form in srfi-42, although ugly, was extremely useful for debugging deeply nested loops.<br><br>F) The :let generator was indispensable  for the Project Euler problems.&nbsp; I know that even I could write a macro for it, but it would be nice to have provided.
<br><br>G)&nbsp; I do not understand :do-in and make-do-sequence well enough, but one of the things that bothers me about the srfi-42 :parallel generator is that the following two fragments to not generate the same result.<br>
<br>(let ([a 1][b 1])<br>&nbsp; (zip<br>&nbsp;&nbsp; (list-ec (:do ((a 0)) (&lt; a 10) ((+ a b))) a)<br>&nbsp;&nbsp; (list-ec (:do ((b 0)) (&lt; b 10) ((+ a b))) b)))<br><br>(let ([a 1][b 1])<br>&nbsp; (list-ec (:parallel<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (:do ((a 0)) (&lt; a 10) ((+ a b)))
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (:do ((b 0)) (&lt; b 10) ((+ a b)))) (list a b)))<br><br>Yes, I know that that is not code that any sane person would write, and I am not sure that it is possible to have the same leakage in for.ss.<br><br>
<br>Sorry for being so whiny,&nbsp; I do greatly appreciate all the work that y&#39;all are doing.<br><br>&nbsp;<br>&nbsp;Deinst<br>