I've removed the constraint on *end*. The text has always said that *end* is an exclusive upper bound, and that should be enough.

I'm still not convinced that the indexer constraint is too restrictive, given that I do not want to provide support compound indexers. SRFI 179 does allow them, but they are restricted to linear transforms only, so that they are just as efficient as simple indexers.

I've filed a finalization PR with Arthur.

On Wed, Aug 26, 2020 at 3:18 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:

There is one issue still open; unfortunately, I just noticed that I
didn't send the email to the list but just to Wolfgang.

I have now forwarded it.

The problem is still the indexer constraint, which doesn't help a lot.
Another thing is that the error condition of numeric-range is
numerically unstable. To solve this second problem, the end argument
should just be interpreted as an upper bound, not a bound that is
exactly reachable in the next step. With this change, (numeric-range
0.0 2.5 1.0) would stand for the sequence 0.0, 1.0, 2.0.

Am Mi., 26. Aug. 2020 um 20:59 Uhr schrieb Arthur A. Gleckler
<xxxxxx@speechcode.com>:
>
> On Wed, Aug 26, 2020 at 11:51 AM Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz> wrote:
>>
>> What work remains to be done on SRFI 196? The last substantial changes
>> were made over three weeks ago, and the ML has been pretty quiet since.
>>
>> Marc suggested[1] that range-indexer could be allowed to return opaque
>> objects. Is there anything else that still needs to be discussed?
>
>
> The only unanswered (in a sense) message about SRFI 169 that I have noted is Vladimir Nikishkin's request for a list of references. John asked him to contribute one, but he didn't reply, so I don't think we have to wait on that, although a list of references would be nice.
>
> I haven't done my final review (that doesn't happen until you call for finalization), but in my notes on the 15th, I wrote that SRFI 196 looked ready.
>
> What do you and John think?