[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SRFI 121: Generators

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.

This seems like a very useful proposal. Comments:

"Using an end-of-file object to indicate that there is no more input" : This is convenient, but gives me pause since a generator is not a "file," so marking the end of a generated sequence with end-of-file is misleading. It's too bad end-of-file isn't just called "end" in R7RS.

make-circular-generator, list->circular-generator: Splitting hairs, but "circular" may not be the best word since it usually describes geometric, not discrete, objects. How about "repeating"?

make-iota-generator: count must be an integer right?

"a sequence of boolean values": capitalize Boolean since it is derived from Boole's name.

make-for-each-generator: obj may be any kind of "collection" but AFAICT that term doesn't have a precise meaning here.

gmerge, gunion, gintersection: The description talks about order but is unclear on whether it means increasing or decreasing order. How about saying "elements in strict increasing order according to a SRFI 114 comparator". The "strict" qualifier implies there are no duplicates in the input.

I think gmerge is capitalized by mistake.

As in SRFI 113, there is the issue in set union that input sets may have elements that are equal according to the comparator but not eqv?. How about copying the SRFI 113 language: "Elements in the result set are drawn from the first set in which they appear."

SRFI 113 also has set difference and xor, include those in SRFI 121?

gtuple: I understand why gzip would be a poor name. This operation is similar to transposing a matrix, would gtranspose be any better?

How about syntax greceive that binds a fixed number of elements to identifiers, similar to SRFI 8 receive?

Kevin Wortman