Sudarshan S Chawathe scripsit:

>   * In the description of make-coroutine-generator, should the
>     occurrences of 'generate' (in text and code) be
>     'make-coroutine-generator' instead?

Fixed.

>   * In the examples just before make-bits-generator, shouldn't the
>     call
>
>     (generator->list (make-reverse-vector-generator '#(a b c d e) 2))
>
>     yield (e d c) instead of (e d c b)?

Fixed.

>     Also nearby, the use of #f as the start argument seems intuitively
>     clear but that usage is not explicitly mentioned.

Changed to 0; there was no intention to support #f.

>   * (minor) In the description of gconcatenate, the last sentence
>     before the code is probably OK but it took me a couple of reads to
>     check possible interpretations.  I am interpreting it as: each
>     returned generator will be tail-called until it returns the eof
>     object before moving to the next.

That sentence makes no sense.  Removed.

>   * In the description of gmerge/gunion/gintersection, I'm a bit
>     unclear on what exactly a caller can expect if the inputs are not
>     sorted as indicated.  Is it considered an error (as in undefined
>     results)?

I changed it to "It is an error if the output of each generator is not
correctly ordered according to <var>comparator</var>."

>   * It is probably something obvious, but why isn't generator-collect
>     called generator-map (similar to gfold/generator-fold)?

Generator-map would imply a map from a generator to another generator,
which is what gmap is, so I gave it a different name.

>   * (minor) The motivation for, and efficiency promise if any, of
>     gfilter-map is unclear to me.

Agreed, it's not worth having.  Removed.

>   * Is (gpairs car-gen cdr-gen) equivalent to
>     (gmap cons car-gen cdr-gen)?

Yes, it is.  Removed.

>   * In the description of glists, 'k' seems undefined.

Changed from "have k items" to "have the expected number of items".

>     Also, the behavior when sizer is a generator is not explicitly
>     mentioned, though an intuitive interpretation is easy to guess
>     (and my guess matched the test in generators-test.scm).

Clarified.

>   * For gindex, is it correct that it is not an error for index-gen to
>     generate indices >= the number of items returned by (a finite)
>     value-gen?

No, it's an error all right.

>   * Question similar to the above for gnth-value, generator-nth: n >=
>     number of items is OK?

For generator-nth, it's an error, but not so for gnth-value;
if there are less than n values in the input, you get a null generator.

>   * The example for gnth-value seems to be missing the 'n' argument.
>     I am guessing that argument should be 2 based on the result
>     there.

Yes, fixed.

>     Is it true that the first element of gen is always
>     returned?

Yes, because its index is 0, which is a multiple of every n.

>   * For generator-last, the behavior for infinite generators seems
>     obvious, but given the "Be careful..." comments for some earlier
>     procedures, it may make sense to add a similar note here.

Done.

>   * Similar to above, for
>
>     (generator-find (lambda (x) #f) infinite-gen)

Done.

>     Perhaps a blanket comment somewhere may be better than the
>     individual ones for such cases.  The very first sentence of the
>     section does indicate "consume all the values" so  perhaps it is
>     fine, but it took me a couple of parses (may be just me!):
>
>      all (the values of the generator passed to them) v.
>
>      (all the values) of (the generator passed to them).

Reworded to "all the values available from the generator that is
passed to them."

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
"The exception proves the rule."  Dimbulbs think: "Your counterexample proves
my theory."  Latin students think "'Probat' means 'tests': the exception puts
the rule to the proof."  But legal historians know it means "Evidence for an
exception is evidence of the existence of a rule in cases not excepted from."