On 2021-06-15 20:57 +0200, Marc Nieper-Wißkirchen wrote:
> I have just taken a brief look at your private git repo for SRFI 224.

Thanks for taking the initiative with this.  Discussing not-yet-published
changes definitely saves additional drafts.

> What is the reason that you do not want the number of values to vary
> between successive steps? For efficiency reasons (allowing fast paths for
> some small fixed arities), it probably makes sense. But then it probably
> also makes sense to explain this reason.

I adopted this, possibly without enough careful thought, from SRFI
43/133's vector-unfold, which is the only other "multiple seed" unfold
I know of.  As you say, this makes sense to me for efficiency reasons;
the all-important one-seed case is less tunable if the number of seeds
may vary.  In contrast, I don't see a compelling case for varying
numbers of seeds.

I will add an explanation of this choice.

> Does the same apply to fxmapping-unfold?

Yes, I intend to add this restriction there, as well.

> Also, I'd suggest allowing an arbitrary number of values added to the stop
> continuation of fxmapping-accumulate that enables communication from values
> inside the loop to the outside world (e.g. some accumulated value).

The beauty of fxmapping-accumulate is that this is unnecessary;
to pass values x1, x2, ..., from inside `proc`, you just call
(values (stop) x1 x2 ...).

Or perhaps I've misunderstood.

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>

"Scientists must be optimists at heart, in order to block out the
incessant chorus of those who say 'It cannot be done.'"
--Academician Prokhor Zakharov