Marc,

Apologies.  I wish I'd forwarded this to the ml when I received it.

On 2020-08-26 21:12 +0200, Marc Nieper-Wißkirchen wrote:
> I would turn "end" into the upper limit, which doesn't have to be
> reached exactly. So, (numeric-range 0 10 11) would produce the
> one-element sequence "0". In other words, you do some rounding down in
> the (end - start) / step calculation. (You have to do some rounding
> anyway due to the possible inexactness.)

This makes sense to me.

> > I do think that we've gone into something of a rat-hole in trying to
> > take into account the possible behavior of inexact numbers under range
> > operations.
>
> What rat hole? The solution is simple (using composed indexers). And
> you can drop the special indexer constraint completely.

I'm willing to switch the implementation back to composed indexers
if that's the consensus.  Nothing important will need to be changed
in the SRFI; we can drop the constraints on indexers completely (as
well as range-lower-bound), at the expense of a small amount of
efficiency.  Composed indexers will probably be hard for a compiler
to optimize.  Consider:

    (range-drop (range b len INDEXER) n)

which is equivalent to

    (range b (- len n) (lambda (b i) (+ (INDEXER b i) n))) .

It seems to me very unlikely that INDEXER will get inlined here.

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

"In the military more is not better." --_Sun Tzu_