Am So., 30. Aug. 2020 um 19:02 Uhr schrieb Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz>:
>
> On 2020-08-29 20:12 -0400, John Cowan wrote:
> > On Sat, Aug 29, 2020 at 1:44 PM Marc Nieper-Wißkirchen <
> > xxxxxx@nieper-wisskirchen.de> wrote:
> >
> > > > Yes.  An obvious extension is to accept #f as the <end> argument of
> > > > numeric-range (or to make <end> optional and reverse the argument
> > > > order), but this would require revision of range-length, range-end,
> > > > and the other procedures which expect ranges to have finite length.
> > >
> >
> > As infinite ranges are inconsistent with the idea of ranges as compact
> > vectors (we don't have infinite vectors), I'm going to rule these out.
>
> Since the "ranges as compact vectors" is now part of the SRFI document,
> I think it's a bit odd that range-map->list and friends have no vector
> counterparts.  I'd propose adding them, since they pose no difficulty:
>
>
> (range-map->vector proc range)
>
> Returns a vector of the results of applying proc to each element of range
> in order. However, the order in which proc is actually applied to the
> elements is unspecified. This procedure must run in O(n) time.
>
> (range-filter->vector pred range)
> (range-remove->vector pred range)
>
> Returns a vector containing the elements of range that satisfy / do not
> satisfy pred. This procedure must run in O(n) time.

I agree that it makes a lot of sense to add them.

In the R7RS (small), it says that "if multiple returns occur from vector-map,
the values returned by earlier returns are not mutated". An analogous
sentence makes sense of the ...->vector procedures. Given the presence
of call/cc, this is the "right thing". (The same applies for the other
higher-order procedures as well, of course, which are generally called
"control-flow" procedures in the report.)

(Unfortunately, most SRFIs are written in a way as if call/cc does not
exist and many are written as if there was no concept of proper tail
calls in Scheme.)

Marc