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.

Of course, these aren't essential and could be relegated to a later
SRFI.

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>

"The Algol compiler was so poorly implemented that we dared not rely
on it, and working with assembler code was considered dishonorable.
There remained only Fortran." --Niklaus Wirth