Sudarshan S Chawathe scripsit:

>   * gcombine: Is it correct that it is not an error for the given
>     generators to have different lengths?  That would be useful.  (The
>     sample implement supports such use.)  An explicit statement either
>     way would help clarify things.

It is not an error, and the next draft will say so.

>   * gdelete-neighbor-dups: Perhaps obvious, but the restrictions on
>     pred could be explicitly noted.  I believe it needs to be an
>     equivalence predicate that can accept objects from gen, including
>     eof-object. (The last part surprised me at first try.)

It is indeed an error if pred is not an equivalence predicate,
but if it is getting eof-objects, that is a bug.

>   * Related to above: Is the result of the following well-defined?
>     It's odd, no doubt, but would seem to be permitted.  The sample
>     implementation goes into an infinite loop.  The description seems
>     to suggest the result should be (1 0 0 0 0).  In any case, some
>     clarification would be helpful.
>
>     (generator->list (gtake (gdelete-neighbor-dups (make-generator 1 2 3)
>                                                    (lambda args #t))
>                             5 0))

Your interpretation seems correct to me, and I don't see any reasonable
alternative interpretation.  The implementation must be buggy.

>   * Similar to above, but for gdrop-while: The following appears
>     permitted but puts the sample implementation into an infinite
>     loop:
>
>       (generator->list (gdrop-while (lambda args #t)
>                                     (make-generator 1 2 3)))

Looks like a gdrop-while bug.  I'll look into it.

>   * gselect: One may expect the following to yield (a d e g h), but
>     the sample implementation yields (a d e h) instead (not
>     unreasonably).  Regardless of which option is chosen, some
>     clarification would be helpful.
>
>       (let ((g (list->generator '(a b c d e f g h))))
>         (append
>          (generator->list (gselect g
>                                    (list->generator '(#t #f #f #t #t #f))))
>          (generator->list g)))
>
>   * The above item (gselect) seems to be a specific instance of a
>     potential ambiguity whenever a procedure takes multiple generators
>     as arguments (with the generators permitted to have different
>     lengths).  For example, I think it applies to gcombine, assuming
>     the generators are not required to have the same length.

This expression is undefined by the rules of Scheme, because its result
depends on the order of evaluation of the arguments of `append`.  The
procedures aren't ambiguous, it's depending on the order of side effects
to the generator without using `begin` to sequence them that's ambiguous.

>   * generator-for-each: A description similar to that in the last
>     paragraph of generator-fold would help clarify the situation when
>     one, but not all, of the generators is exhausted.

I will do this.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
Real FORTRAN programmers can program FORTRAN in any language.  --Ed Post