General question Marc Nieper-Wißkirchen (02 May 2020 18:59 UTC)
Re: General question Linus Björnstam (03 May 2020 17:12 UTC)
Re: General question Marc Nieper-Wißkirchen (03 May 2020 17:48 UTC)
Re: General question John Cowan (03 May 2020 17:56 UTC)
Re: General question Marc Nieper-Wißkirchen (03 May 2020 18:09 UTC)
Re: General question Lassi Kortela (03 May 2020 18:09 UTC)
Re: General question Lassi Kortela (03 May 2020 18:12 UTC)
Re: General question Linus Björnstam (03 May 2020 20:02 UTC)
Re: General question Marc Nieper-Wißkirchen (04 May 2020 06:34 UTC)

Re: General question Marc Nieper-Wißkirchen 04 May 2020 06:34 UTC

Am So., 3. Mai 2020 um 22:02 Uhr schrieb Linus Björnstam
<xxxxxx@veryfast.biz>:

> 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.

Apart from that the SRFI 171 handles the state explicitly, I can also
precompose an accumulator of SRFI 158 with a "transducer". E.g. if `a'
is an accumulator, a new one is

(lambda (x) (when (or (eof-object? x) (odd? x)) (a x)))

In the sense of SRFI 171, the transducer is therefore

(lambda (a)
  (lambda (x) (when (eof-object? x) (odd? x)) (a x)))

It's true that SRFI 158's accumulator API is, compared to the
generator counter-part, impoverished.

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

This analog in the world of generators and accumulators would be a
procedure taking a generator and an accumulator:

(lambda (g a)
  (do ((x (g x) (g x))
      ((eof-object? x) (a x))
    (a x)))

Here, the state of `g' and `a' is implicit. If there is are explicit
state objects that have to be passed around, this can easily be done
in the do loop.

[...]

> 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).

`push-to-channel!' would be an accumulator. The generator is implicit
in `list-transduce', `port-transduce', or whatever you use to start
the reduction.

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

I wish him (and you) a speedy recovery!

Marc