On 2020-08-30 21:29 +0200, Marc Nieper-Wißkirchen wrote:
> 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.

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

Agreed.  The second, delayde version could be especially bad if PROC
is expensive.

In essence, we want range-map, et al, to be strict in their application
of procedures to range elements.

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

"We have lost exactly what we wanted to lose." --Fong & Spivak