[Hopefully not a duplicate; I used an incorrect email identity earlier.]

Here are some minor comments based on things that confused me a bit as
I read the SRFI 121 draft #5 (2015/10/19).  I hope they are not too
late given the recent "last call" for comments.  In any case, they are
all just minor suggestions for (arguably) making things a bit easier
to understand, and some are probably just confusions at my end.

  * The following appears in Rationale:

      The combination of make-for-each-generator and generator-unfold
      makes it possible to convert any collection that has a for-each
      procedure into any collection that has an unfold constructor.

    I didn't understand it at this point (and so just skipped over,
    without any problems). It also took me a while to figure it out
    when I returned to it after reading the rest.  An example near the
    end of the SRFI, where generator-unfold is defined, would be a big
    help, I think.

  * There is a typo "itt" in the Rationale text.

  * make-bits-generator: To check my understanding, there is no
    (simple) way to use this procedure to create a generator that
    gives a single 0 or 1 bit, correct?  (I don't see it as a problem,
    given that we have simpler ways to do it, though I guess it may
    add a special case or two to code that uses it.)

  * make-port-generator: I believe the bold instances of "port" in the
    description should read "input-port".

  * make-port-generator: The finiteness of the resulting generator
    also depends on 'reader', correct?  It would probably be very odd,
    but the description seems to permit 'reader' to do things other
    than returning an eof-object when data from the port is exhausted.
    Perhaps some contract is implied by calling it 'reader', though.

  * Is it true that there is no tail-call guarantee for gappend?

  * Including duplicates in the example for gdelete may provide a
    better illustration of its action:

    (generator->list (gdelete (make-generator 1 2 3 4 5 3 6 7)))
    => (1 2 4 5 6 7)

  * Similar to above, to illustrate gdelete-neighbor-dups:

    (generator->list (gdelete-neighbor-dups
    		     (make-generator a a b c a a a d)))
    => (a b c a d)

  * gselect: Is there any guarantee regarding whether one generator
    will be called after the other has been exhausted?  Perhaps it's
    unimportant; I don't have a use case in mind.

  * generator-unfold: An example would be very useful here to clarify
    matters, I think (related to the very first item above).

Regards,

-chaw