Really expose range-indexer? Marc Nieper-Wißkirchen (31 Aug 2020 18:35 UTC)
Re: Really expose range-indexer? Wolfgang Corcoran-Mathe (31 Aug 2020 19:11 UTC)
Re: Really expose range-indexer? Marc Nieper-Wißkirchen (31 Aug 2020 19:23 UTC)
Re: Really expose range-indexer? Marc Nieper-Wißkirchen (31 Aug 2020 19:31 UTC)
Re: Really expose range-indexer? John Cowan (01 Sep 2020 02:44 UTC)

Re: Really expose range-indexer? Marc Nieper-Wißkirchen 31 Aug 2020 19:31 UTC

... or, more succinctly, something like

make-functional-range

or

make-procedural-range

as in the various make-XXX-generator procedures in SRFI 158.

Alternatively,

range-tabulate

as in list-tabulate of SRFI 1. The latter, however, apply the indexer
procedure eagerly, while SRFI 196 does it lazily.

So, maybe, range-tabulate should be a different procedure defined by

(define (range-tabulate n indexer)
  (vector->range (vector-unfold indexer n)))

Alternatively, call it

range-unfold

with arguments as in vector-unfold.

Yes. that's probably the best: Range becomes (make-)procedural-range
and range-unfold is added.

Sorry for the wordy email; I have been thinking aloud while typing. :)

Marc

Am Mo., 31. Aug. 2020 um 21:22 Uhr schrieb Marc Nieper-Wißkirchen
<xxxxxx@nieper-wisskirchen.de>:
>
> Am Mo., 31. Aug. 2020 um 21:11 Uhr schrieb Wolfgang Corcoran-Mathe
> <xxxxxx@sigwinch.xyz>:
>
> > On 2020-08-31 20:35 +0200, Marc Nieper-Wißkirchen wrote:
> > > As it is not clear to me what is a good use case of range-indexer
> > > after all, I would consider dropping the procedure.
> >
> > Agreed.  It should be dropped.  I can't think of any reason to expose
> > it, especially since some range operations return ranges whose indexers
> > have unpredictable behavior on their own--i.e. without taking into
> > account the `start-index' and `length' bounds of a range.
>
> Conceptually all this means that a range is no more just a (logical)
> pair consisting of a length and an indexer. Therefore, it may make
> sense to rename
>
> range => make-range
>
> -- Marc