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.
Sudarshan S Chawathe scripsit: > * In the description of make-coroutine-generator, should the > occurrences of 'generate' (in text and code) be > 'make-coroutine-generator' instead? Fixed. > * 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)? Fixed. > Also nearby, the use of #f as the start argument seems intuitively > clear but that usage is not explicitly mentioned. Changed to 0; there was no intention to support #f. > * (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. That sentence makes no sense. Removed. > * 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)? I changed it to "It is an error if the output of each generator is not correctly ordered according to <var>comparator</var>." > * It is probably something obvious, but why isn't generator-collect > called generator-map (similar to gfold/generator-fold)? Generator-map would imply a map from a generator to another generator, which is what gmap is, so I gave it a different name. > * (minor) The motivation for, and efficiency promise if any, of > gfilter-map is unclear to me. Agreed, it's not worth having. Removed. > * Is (gpairs car-gen cdr-gen) equivalent to > (gmap cons car-gen cdr-gen)? Yes, it is. Removed. > * In the description of glists, 'k' seems undefined. Changed from "have k items" to "have the expected number of items". > 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). Clarified. > * 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? No, it's an error all right. > * Question similar to the above for gnth-value, generator-nth: n >= > number of items is OK? For generator-nth, it's an error, but not so for gnth-value; if there are less than n values in the input, you get a null generator. > * 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. Yes, fixed. > Is it true that the first element of gen is always > returned? Yes, because its index is 0, which is a multiple of every n. > * 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. Done. > * Similar to above, for > > (generator-find (lambda (x) #f) infinite-gen) Done. > 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). Reworded to "all the values available from the generator that is passed to them." -- John Cowan http://www.ccil.org/~cowan cowan@xxxxxxxx "The exception proves the rule." Dimbulbs think: "Your counterexample proves my theory." Latin students think "'Probat' means 'tests': the exception puts the rule to the proof." But legal historians know it means "Evidence for an exception is evidence of the existence of a rule in cases not excepted from."