Here are some comments on SRFI 121 Draft #6 (2015/10/25).  Some are
very minor suggestions, but there are few small bugs and a question
too.

  * (very minor) The template "bytevector->generator str..." may be
    reworded as "bytevector->generator bvec..." or similar, by analogy
    with the other names.

  * The examples that use make-vector-generator should use
    vector->generator instead; similarly, the instances of
    make-reverse-vector-generator should read
    reverse-vector->generator.

  * (discussion correction; nothing to do in document itself)
    Correction to my misstatement in an earlier message: We can use
    make-bits-generator to create a generator that yields just a
    single #t; it's yielding a single #f that's not feasible with this
    constructor.

  * The sample implementation of make-port-generator returns the
    result of evaluating read-line instead of returning a thunk that
    does that.

  * (very minor) Unneeded (I think) FIXME comment in
    generators-impl.scm for make-for-each-generator.

  * (very minor) Extra quote in return value of example just before
    Generator operations section.

  * Result of the example for gdelete-neighbor-dups is missing a final
    c.

  * Does gindex provide a guarantee similar to the last sentence of
    the description of gselect (would be nice)?  To illustrate, is the
    following an error?

      (gindex (list->generator '(a b c))
              (list->generator '(0 2 4 6))))

  * For generator-unfold: The order of argument in the example doesn't
    match those in the spec and sample implementation.

  * In the example for generator-unfold (assuming the order of
    arguments is fixed as above): SRFI-1 unfold requires an additional
    argument (initial seed), so it still doesn't work unless we say
    something like:

      (generator-unfold (make-for-each-generator string-for-each "abc")
			unfold #\z)

Regards,

-chaw