Am Mo., 24. Aug. 2020 um 20:01 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

> [-srfi-178]
> [+scheme-reports-wg2]

We would have to forward the whole discussion so that it can make
sense for the WG 2 members.

> On Mon, Aug 24, 2020 at 11:45 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:

>> Now that I have looked up "list-tabulate" of SRFI 1, I see that it
>> doesn't take any seeds and that the procedure doesn't deliver the next
>> set of seeds.

> No need, since the only seed is 0 and the successor procedure is (cut + 1 <>).

I didn't mean the implementation of list-tabulate in terms of unfold,
I meant the following:

We have

(list-tabulate n proc),

whose vector-equivalent is (arguably mistakenly named)

(vector-unfold proc n).

(The reversal of arguments is another unfortunate inconsistency, but I
haven't been talking about this one.)

The vector-unfold procedure allows taking extra seeds to thread state
through the iteration. There is no reason, why list-tabulate shouldn't
be extended:

(list-tabulate n proc seed* ...)

Given vector-unfold, the definition would be:

(vector->list (apply vector-unfold proc n seed*))

>> Any ideas to get out of this unfortunate Babylonian confusion?

> Not really.  What can't be cured must be endured.

One cure would be to add new sets of names for the streamlined
procedures and deprecate (but support) the old names.

> xxxxxx@googlegroups.com would be the right place to discuss it, so I'm responding there.  I see that your xxxxxx@gmail.com address is subscribed, but not your nieper-wisskirchen.de address.

Thanks for the reminder. This is my own Babylonian confusion. :)