This page is part of the web mail archives of SRFI 121 from before July 7th, 2015. The new archives for SRFI 121 contain all messages, not just those from before July 7th, 2015.
I find this SRFI very interesting from a user perspective. I have
noted below the items the confused me a bit, at least for a while.
Sorry for the long message.
* In the description of make-coroutine-generator, should the
occurrences of 'generate' (in text and code) be
'make-coroutine-generator' instead?
* In the examples just before make-bits-generator, shouldn't the
call
(generator->list (make-reverse-vector-generator '#(a b c d e) 2))
yield (e d c) instead of (e d c b)?
Also nearby, the use of #f as the start argument seems intuitively
clear but that usage is not explicitly mentioned.
* (minor) In the description of gconcatenate, the last sentence
before the code is probably OK but it took me a couple of reads to
check possible interpretations. I am interpreting it as: each
returned generator will be tail-called until it returns the eof
object before moving to the next.
* In the description of gmerge/gunion/gintersection, I'm a bit
unclear on what exactly a caller can expect if the inputs are not
sorted as indicated. Is it considered an error (as in undefined
results)? The description says only that the result won't be
ordered, seeming to suggest other properties will still be
satisfied. For example, would a gunion still remove duplicates?
Intuitively, I suspect the answer should be no.
* It is probably something obvious, but why isn't generator-collect
called generator-map (similar to gfold/generator-fold)?
* (minor) The motivation for, and efficiency promise if any, of
gfilter-map is unclear to me.
* (minor) Given the examples elsewhere, an example for
gbuffer-filter may make its use clearer. (I found one in
generators-test.scm.)
* Is (gpairs car-gen cdr-gen) equivalent to
(gmap cons car-gen cdr-gen)?
* In the description of glists, 'k' seems undefined.
Also, the behavior when sizer is a generator is not explicitly
mentioned, though an intuitive interpretation is easy to guess
(and my guess matched the test in generators-test.scm).
* For gindex, is it correct that it is not an error for index-gen to
generate indices >= the number of items returned by (a finite)
value-gen?
* Question similar to the above for gnth-value, generator-nth: n >=
number of items is OK?
* The example for gnth-value seems to be missing the 'n' argument.
I am guessing that argument should be 2 based on the result
there. Is it true that the first element of gen is always
returned?
* For generator-last, the behavior for infinite generators seems
obvious, but given the "Be careful..." comments for some earlier
procedures, it may make sense to add a similar note here.
* Similar to above, for
(generator-find (lambda (x) #f) infinite-gen)
Perhaps a blanket comment somewhere may be better than the
individual ones for such cases. The very first sentence of the
section does indicate "consume all the values" so perhaps it is
fine, but it took me a couple of parses (may be just me!):
all (the values of the generator passed to them) v.
(all the values) of (the generator passed to them).
Only the first makes sense for generator->list, so my confusion was
quickly resolved.
Regards,
-chaw