vector->range issues
Wolfgang Corcoran-Mathe
(01 Sep 2020 19:21 UTC)
|
Re: vector->range issues
Marc Nieper-Wißkirchen
(01 Sep 2020 19:28 UTC)
|
Re: vector->range issues
Wolfgang Corcoran-Mathe
(01 Sep 2020 20:52 UTC)
|
Re: vector->range issues
Marc Nieper-Wißkirchen
(02 Sep 2020 05:48 UTC)
|
Re: vector->range issues
Marc Nieper-Wißkirchen
(02 Sep 2020 07:57 UTC)
|
string-range Marc Nieper-Wißkirchen (02 Sep 2020 13:14 UTC)
|
Re: string-range
Wolfgang Corcoran-Mathe
(02 Sep 2020 14:50 UTC)
|
Re: string-range
Marc Nieper-Wißkirchen
(02 Sep 2020 15:01 UTC)
|
Re: string-range
Wolfgang Corcoran-Mathe
(02 Sep 2020 15:56 UTC)
|
Re: string-range
Marc Nieper-Wißkirchen
(02 Sep 2020 15:58 UTC)
|
Re: string-range
John Cowan
(02 Sep 2020 21:12 UTC)
|
Re: string-range
Wolfgang Corcoran-Mathe
(02 Sep 2020 21:16 UTC)
|
Re: string-range
Wolfgang Corcoran-Mathe
(02 Sep 2020 21:25 UTC)
|
Re: vector->range issues
Wolfgang Corcoran-Mathe
(02 Sep 2020 14:46 UTC)
|
The more I think about it, the more I like the vector->range/vector-range pair. The first is conceptionally a conversion function, the latter a constructor. In this spirit, I would also want to suggest (string-range STRING) a range constructor that takes a string and does the obvious thing. As with vector-range, the argument mustn't be modified later. The rationale for adding string-range is special. There have been many attempts to ensure O(1) reference to string characters, e.g. string cursors, UTF-32 encoding, texts, immutable strings, ... Now, string-range is a cheap and obvious solution. An implementation. which has O(1) access time for whatever reasons, would define (define (string-range s) (range (string-length s) (lambda (i) (string-ref s i)))) An implementation, which has O(n) access time for strings, would define (define (string-range s) (vector-range (string->vector s))) The nice thing is it is transparent for the user who just wants to examine a string character-wise. He or she just has to work with (string-range s) instead of s directly. The icing on the cake is that the operations range-split-at and range-append, which may be used in the further processing of the string, are extremely cheap compared to string-copy and string-append. Marc Am Mi., 2. Sept. 2020 um 09:57 Uhr schrieb Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de>: > > > Rename it to > > > > ivector->range > > > > ? > > Better suggestion: > > (vector-range VECTOR) > > wraps VECTOR in a range. > > (vector->range VECTOR) > > copies the vector first. > > The naming vector-range is consistent with numeric-range and other > range-constructors we may conceive in the future.