gcombine's functinality is similar to mapAccum in Haskell; each seed value depends

on previous calculations. To implement it by gmap you need a mutable state,

something along this line:

(define (gcombine proc seed . gens)

(apply gmap (lambda vs (receive (val next) (apply proc (append vs (list seed)))

(set! seed next)

val))

gens))

Given that generators are inherently stateful object, it may not be as important

to have both gcombine and gmap as to have both map-accum and map.

On Sat, Jan 9, 2016 at 5:26 PM, Per Bothner <xxxxxx@bothner.com> wrote:

Two notes and a meta-note. First the meta-note:

Overall, this seems a useful and reasonable SRFI. However,
I reserve judgment about whether it belongs in R7RS-large.

make-bits-generator n
It is worth noting that the last element if (> n 0) is #t,
while the last element if (< n -2) is #f.
Unfortunately, both (= n 0) and (= n -1) return the empty generator.
So make-bits-generator is *almost* invertible.
The specification could mention one way to extend the bits list
with one more bit to represent the inifinite rest:
(gappend (make-bits-generator n) (generator (>= n 0)))
(ITOH since I don't have a use-case for make-bits-generator,
or for inverting it, I don't know if this is an issue.)

gcombine proc seed gen gen2 …
IMO It would be more natural for proc to not take a seed.
Instead we should standardize gmap:
(gmap proc gen1 gen2 ...) where proc is called as (proc v1 v2 ...)
I note gcombine doesn't add any functionality beyond gmap:
(define (gcombine proc seed . gens)
(apply gmap (lambda vs (apply proc (append vs (list seed))) gens)))

or using Kawa's more readable splice syntax:

(define (gcombine proc seed . gens)
(gmap (lambda vs (proc @vs seed)) @gens))

--
--Per Bothner
xxxxxx@bothner.com http://per.bothner.com/