Am Fr., 31. Juli 2020 um 19:33 Uhr schrieb Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz>:

> range-split-at doesn't necessarily involve rounding problems, I think.

Not necessarily, but it will unless you use what you call composed indexers.

> 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?

Indeed, the solution is a composed indexer. I don't think it's that
bad as the algorithmic complexity wouldn't change. And as soon as we
have composed indexers, many more things become possible like
range-map.

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

Yes, and it's good if ranges are not completely trivial so that they
effectively solve a non-trivial problem.

P.S.: It is possibly a good idea to allow abstract entities for
indexers and not only procedures. The problem is that procedures
(which are actually closures) cannot be introspected. This way, the
complexity can only increase when indexers are composed and the
implementation can never simplify indexers. To cure this, you have to
allow that range-indexer returns opaque values.