Am Sa., 22. Aug. 2020 um 18:23 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Sat, Aug 22, 2020 at 2:27 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>
>>> Exactly so; thanks for the concise expression.  I think that Marc's complaint is mostly terminological: we shouldn't call it an unfold when it isn't.
>>
>>
>> Yes. Exactly. Especially as tabulate is be more common or easier to understand.
>
>
> I don't think it's more commonly used (ah for the good old Google code search!).  It also puts more of the burden on the user-supplied proc, whereas unfold handles state internally to itself.  I would not want to use tabulate except where the proc is already stateless.

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.

So what I have been really talking about is a mixture between
"list-tabulate" and "vector-unfold": The semantics of "vector-unfold"
and the name of "list-tabulate".

An extension of "list-tabulate" to allow seeds is both a natural thing
to do and could be added to R7RS-large while keeping SRFI
1-compatibility. The only problem is then really the naming. The
vector equivalent of "list-tabulate" would be "vector-unfold", which
in turn, is not the vector equivalent of "(list-)unfold".

Any ideas to get out of this unfortunate Babylonian confusion?

PS While I am writing this on the mailing list of SRFI 178, we cannot
slice the Gordian knot here. It is the same situation with the
irregular "=" (vs "=?") suffixes and irregular orderings of folds (as
in SRFI 1). But we should try to find a pleasant solution while the
development of R7RS-large is still going on.