On Sun, 3 May 2020, at 19:48, Marc Nieper-Wißkirchen wrote:
> Hi Linus,
>
> I suppose that you call a generator's semantics a pull semantics. So
> an accumulator in the sense of SRFI 158 will have a push or eager
> semantics, right? So SRFI 158 can support both styles.
>
> In SRFI 171, the procedures that apply transducers (like
> LIST-TRANSDUCE) act like generators The reducers of SRFI 171
> correspond to accumulators while the transducers are maps that are
> eventually to be composed with accumulators.
>
> Is this correct?

I don't know if I understand what you mean. ((compose (tfilter odd?) (tmap (lambda (x) (* x x)))) rcons) returns a reducer in the sense like cons or + can be used in srfi-1 fold. you push one a new value and the current state through and get a new state back.

list-transduce takes a transducer, a reducer, optionally a seed, and a list. It calls the transducer with the reducer which returns a new reducer (with a clean state if any transducer is stateful). It then reduces over the list with that reducer, just like fold of srfi-1 with the exception that it checks for a <reduced> value which ends the reduction.

Your description could possibly fit that. I am not really sure where you want to come with that. I am pretty sure about the details of transducers, but my generator usage is mostly confined to my usage of coroutine generators in guile (which are fast, using delimited continuations).

>
> So the remaining difference to SRFI 158 seems to be that in the SRFI
> 171 model an explicit state ("result-so-far") is threaded through,
> while in the SRFI 158 model, an accumulator has to keep some internal
> state (and is thus less pure).

Yes, and the fact that, due to eagerness, the state can be managed within the reduction and is never passed to the user.

> Thus, I am wondering whether on can conflate both concepts into one of
> generators and accumulators that are based on some state that is
> threaded through (I am thinking of Haskell's state monad here).

I am sure they can be. There is a javascript library that implements transducers as es6 generators. I am not sure, however, how they compare to srfi-171.

The thing I am not sure how I would implement using generators is the following:

(define maybe-push-to-channel ((compose (tfilter valid-thing?) (tmap process-data)) push-to-channel!))
(maybe-push-to-channel 'fail-value "my data to push!")

maybe-push-to-channel is a reducer that, if it succeeds, runs push-to-channel! with ('fail-value whatever-makes-it-though).

The transducer in question could potentially have been provided by the user.

Sorry for the badly written email. My son has flu and sleeps only sporadically.

/Linus