Am Fr., 28. Aug. 2020 um 20:10 Uhr schrieb Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz>:
>
> On 2020-08-28 19:03 +0200, Marc Nieper-Wißkirchen wrote:
> > And what do you think of my vector->range proposal? I find it rather obvious.
>
> While I'm not sure I see much utility in vector->range (SRFI 133
> provides many ways of iterating over vectors) I think we may want this

On its own, it is not very helpful as you say because SRFI 133
provides enough. But it could be useful when used with code that
expects ranges.

> and other X->range conversions.  As SRFI 196 has already passed the

list->range is less obvious than vector->range and would have to be
implemented as (vector->range (list->vector LIS)) because of the O(1)
guarantees. The same would hold for generator->range. Therefore, we
don't need more than this single converter.

So it is just about this single procedure.

> 90-day mark, though, I propose that these be specified in a
> supplemental ranges SRFI.  I'd also like to see ways to compose
> ranges--e.g. a range-product function for producing the product of a
> set of ranges--in such a SRFI.

range-map could also go into such a SRFI. Such a SRFI would, however,
need composed indexer procedures.

Have you also thought about potentially infinite ranges?

PS In the rationale, you make the excellent point about

(range-for-each (lambda (i) ...) (numeric-range 0 1000000))

being much better than the same expression with for-each and iota.

What is missing though, is the better version of:

(for-each (lambda i elm) (iota 0 <some-very-large-number>) lis)

Here, we want to zip a (potentially infinite) range with a list.
Thanks to the short-circuiting of for-each, when any of the lists
ends, the space needed should be proportional to the length of the
list.

I know how it can be solved with generators, but as being part of the
rationale for ranges, it would be nice to see a compelling use case of
ranges that works not only for the single list case.