Just a few comments before finalization:

- In the rationale it says that "(numeric-range 0.0 1.0 0.1) specifies
the sequence 0.0, 0.1, ... 0.9". This is not universally true due to
"0.x" being in inexact number and the possibility of rounding errors.
Unlikely, but I would add a warning that the length of inexact ranges
is not well defined but can be off by 1.

- Is "range?" deliberately underspecified? At the moment, "range?" is
allowed to return "#t" on, say, exact integers if the various
procedures are able to interpret exact integers as ranges (which can
make sense, e.g., an exact integer n could stand for the range 0 ... n
-1).

- There is a note: "The size of a range object is independent of the
number of elements it contains." While I understand what you mean,
this is not completely true because large numbers space proportional
to O(log n) and not O(1). So O(log n) is a better limit. Moreover,
demanding "independence" does not allow for shorter representations of
some ranges (like exact ranges of the form 0 ... n - 1).

- The algorithmic complexities cannot be achieved if the comparator
does not return its result in O(1). However, a comparator does not
have a prescribed complexity. In fact, most comparators will return
their result in O(log n) or in O(n) when n is the absolute value of
the number or the length of the datum.

- The implementation of "numeric-range" does seem to assume that
rounding errors cannot happen when computing the length. I think a
test has to be added whether "start + calculated-len * step < end" but
"start + (calculated-len - 1) * step >= end".

Marc

Am Di., 28. Juli 2020 um 02:24 Uhr schrieb Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz>:
>
> On 2020-07-27 18:56 -0400, John Cowan wrote:
> > We can finalize this on Wednesday or Thursday unless anyone
> > thinks more discussion is needed.
>
> Agreed.
>
> --
> Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>
>
> "More shall come after us than have gone before; the world
> is not yet middle-aged." --Herman Melville, _White-Jacket_