It does to me.  Can you propose appropriate language for the SRFI?

On Sun, Aug 30, 2020 at 5:06 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
Am So., 30. Aug. 2020 um 22:56 Uhr schrieb Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz>:
>
> On 2020-08-30 22:43 +0200, Marc Nieper-Wißkirchen wrote:
> > Am So., 30. Aug. 2020 um 22:40 Uhr schrieb Wolfgang Corcoran-Mathe
> > <xxxxxx@sigwinch.xyz>:
> >
> > > Agreed.  The second, delayde version could be especially bad if PROC
> > > is expensive.
> >
> > Or good because of the O(n) behavior of the first version. But that's
> > just an observation and doesn't invalidate the argument.
>
> So what's it to be?  It seems to be a trade-off.  Both approaches have
> their uses, though it's not Scheme tradition to provide two versions of
> the same procedure with different evaluation strategies.

Oh, apparently I wasn't clear enough. I didn't want to invalidate the
overall argument and didn't want to open the can of worms again.

While both semantics have their uses, for ranges, the strict semantics
(the one suggested by John's wording) is the right (at least I believe
so).

For infinite progressions, it necessarily has to be the other (see my
list/generator map comparison).

So we don't have to provide two versions of the same procedure with
different evaluation strategies. We provide two different ones for
different object types: one for ranges, strict and suitable for the
finite objects, and one for infinite progressions, defered and the
only possible there.

Does it make sense?

Marc