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 03 May 2020 18:09 UTC

Am So., 3. Mai 2020 um 19:55 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
> It is perfectly possible to extend SRFI 158 gen/acc procedures by allowing additional arguments.  I would suggest an additional optional argument which is an alist mapping symbols (representing purposes such as "state" or "finalizer") to values interpretable by the particular gen/acc procedure.  Unknown symbols would be ignored.

Could you give a brief example?

If I understand correctly, given a generator `g', we want to be able
to call it like `(g x ...)', where `x' are some values (like in
Python's enhanced generators where the send method can take
arguments). For symmetry reasons, an accumulator can return values
whenever new values are fed into the accumulator.

(This seems to be an example for why it would be nice if the SRFI 158
generators and accumulators were multiple values-aware. To make the
accumulator pure, I would like to be able to feed two values on each
iteration into it. In the language of SRFI 171 this would be
"result-so-far" and "input". Likewise, we would like that generators
can return multiple values on each iteration so that both the state
(to be provided in the next iteration) and the actual output can be
delivered by the generator. Once SRFI 189 is done, we should really
think of a generator/accumulator concept that handles multiple values
and which can subsume transducers.)