On 2020-07-31 08:14 +0200, Marc Nieper-Wißkirchen wrote:
> And I think I made a mistake in my previous post. A procedure
> "range-map" would be possible, wouldn't it? The mapping procedure
> would just have to be post-composed with the indexer, wouldn't it? If
> that's the case, I would propose to add this one (and this time before
> finalization).

Yes, I'd like to have range-map.  Composing procedures with the
indexer has implications for the complexity of later range
operations, though.

> - range-split-at has rounding problems for numeric ranges, hasn't it?
> In fact, it seems to assume the following more general constraint on
> indexers:
>
> (indexer lower-bound (+ k l)) is equal to (indexer (indexer lower-bound k) l)
>
> As one sees from the example of numeric ranges, we don't want to
> guarantee such a constraint.

range-split-at doesn't necessarily involve rounding problems, I think.
As currently implementated it may (for ranges with inexact elements,
of course).  An implementation could avoid this (I believe) by giving
both subranges the old lower bound and passing the second range a
composed indexer, e.g. (lambda (b n) (old-indexer b (+ n index))).
The same goes for the range-drop, subrange, etc.  For a short while,
this is how the sample implementation handled these cases, as a way to
deal with more unorthodox ranges.

But composing indexers means that the results of subrange operations
will have slower indexers than the original ranges.  A dislike of this
ugliness is why I pushed for a constraint which would allow lower
bounds to be changed instead.  I understand now (thanks!) that this
constraint is too restrictive on inexact ranges.  So what's the
solution?

I think this is *the* challenge to solve with ranges.

> So range-split-at has to use a custom indexer for the second
> subrange.

Would this mean an extra indexer argument to range-split-at ?  If so,
would the new indexer be expected to compute elements from the old
lower bound?

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

"I have discovered a truly marvelous implementation of this
function which this 80-column limit is too narrow to contain."
--fishythefish