Am So., 30. Aug. 2020 um 20:46 Uhr schrieb Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz>:
>
> On 2020-08-30 14:21 -0400, John Cowan wrote:
> > On Sun, Aug 30, 2020 at 1:02 PM Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz>
> > wrote:
> >
> > (range-map->vector proc range)
> > > (range-filter->vector pred range)
> > > (range-remove->vector pred range)
> > >
> >
> > Added, along with range-map, range-filter, and range-remove, all of which
> > return "vector-type" ranges.

While range-map->vector has a clear semantics, the best semantics is
not so obvious. When you write "return 'vector-type' ranges", you seem
to mean that

(define (range-map proc range)
  (vector->range (range-map->vector proc range))

The following definition, however, is at least equally sensible:

(define (range-map proc range)
  (range (range-length range)
             (lambda (k) (proc (range-ref range k)))))

Both possibilities have their advantages and disadvantages. The former
has time and space complexity of O(n), the latter of O(1). While the
former calls PROC upon construction, the latter calls PROC at
reference time. This difference is akin to the one between (list-)map
and gmap (of SRFI 158). Due to the way generators work, gmap has the
guarantee (in the absence of call/cc) that PROC is only called once
per index, whereas the second version of range-map has no such
guarantee.

When we view ranges as finite sequences, the first definition of
range-map seems to make more sense. The second definition is more
suited to potentially infinite "ranges" and should be left to a later
SRFI dealing with potentially infinite "ranges".

The description of "range-map" and the other procedures in the SRFI
should exclude the possibility of the second definition.

Marc

PS Speaking of potentially infinite "ranges", I want to suggest a SRFI
"Progression Objects" akin to this SRFI. In the sense that ranges are
compact vectors, progressions are compact generators with random
access as for vectors. Here, the higher-order procedures
("progression-map") would defer the application of the PROC argument.
Compared to ranges, the length information will be more complicated
(exact length, infinite length, length bounded below or above, ... may
all be possible) and the running time guarantees are not as obvious.
If you want, I can propose an API once my pipeline has a bit room.