Comments on SRFI 121 Draft 8 (2015/11/08). Sudarshan S Chawathe (08 Nov 2015 23:02 UTC)
Re: Comments on SRFI 121 Draft 8 (2015/11/08). John Cowan (09 Nov 2015 02:57 UTC)
Re: Comments on SRFI 121 Draft 8 (2015/11/08). Sudarshan S Chawathe (09 Nov 2015 03:24 UTC)

Comments on SRFI 121 Draft 8 (2015/11/08). Sudarshan S Chawathe 08 Nov 2015 23:02 UTC

Here are some comments on SRFI 121 draft #8 (2015/11/08) and the
sample implementation of the same date; md5sum for reference:

    6d15421c30eebcf97ba420b52d35cb40  generators.tar.gz

  * 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.

  * 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.)

  * 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))

  * 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)))

  * 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.

  * generator-fold: Similar to the above two items, though the last
    paragraph of the description here does imply that one extra item
    will be consumed form each generator that is not exhausted when
    any one of them is exhausted.

  * 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.

Regards,

-chaw