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