Am So., 30. Aug. 2020 um 23:08 Uhr schrieb Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz>:
>
> Additional note: The O(n) space complexity of the "vectorizing"
> range-map is actually its worst aspect, I think.  This violates the
> compact nature of ranges, as the entire range must be realized as a
> vector which is then enclosed in a new range:
>
>     (range-map square (numeric-range 0 10000))
>
>     ==
>
>     (vector->range (vector-map square #(0 ... 9999)))
>
> So we can no longer rely on the crucial principle stated near the
> beginning of SRFI 196: "The size of a range object is independent of
> the number of elements it contains".

The sentence "The size of a range object is independent of the number
of elements it contains" has not really a formal meaning (and should
thus be moved from the specification section into the informal
rationale). You can always hide whatever space and time complexity in
the indexer procedure.

It's the same with range-map. Thus I don't see a fatal contradiction here.

Of course, for your example with (range-map square (numeric-range 0
10000)), it is hurting but just shows that range-map is not the right
tool for *this* particular use case. For that we would want to use

(progression-map square (numeric-progression 0 10000))