Re: bytevector-string-ref

[lloda]

> On 22 Dec 2022, at 09:58, Sascha Ziemann <ceving@gmail.com> wrote:
> 
>>> (define str "Hello, World!")
>>> (define bv (string->utf8 str))
>>> (define sa (make-shared-array bv (lambda (i) (list (+ i 7))) '(0 4)))
>> 
>> I think this should be
>> 
>>  (define sa (make-shared-array bv (lambda (i) (list (+ i 7))) 4))
> 
> This seems to be the same (equal?):
> (make-shared-array bv (lambda (i) (list (+ i 7))) '(0 4))
> (make-shared-array bv (lambda (i) (list (+ i 7))) 5)
> 
> And it does not work either:
> In procedure utf8->string: Wrong type argument in position 1
> (expecting bytevector): #1vu8(87 111 114 108)
> 
> #1vu8() and #vu8() seem to be diverse. Btw what is the difference?

#vu8() are containers. These objects consist of a piece of storage and its size.

#1vu8() are views (specifically, rank-1 views). These are more complicated 
objects that contain a pointer to a container plus size, start location, and 
stride. Internally, views are their own type ('arrays') and not bytevectors.

In Guile, functions that have 'array' in their name take either containers or 
views of any type, so array-ref for example will accept #1vu8() or #vu8() or 
#f32() or even #(). However this generality makes them slower than 
type-specific functions such as bytevector-ref or f32vector-ref and so on.

If you make a shared array of a bytevector that isn't the bytevector itself 
(start at 0, end at end, stride 1) you'll get a view and not a bytevector, 
because the bytevector object cannot represent such a shared array. Once you 
use make-shared-array, you're limited to the array-xxx functions.

It used to be the case that some typed vector functions worked on views was 
well. For example, we used to have vector-ref which worked on #1() and #(), and 
simple-vector-ref that worked only on #(). It was a bit of a mess. That was 
never the case of the bytevector functions, which were added later and only 
ever worked on bytevector objects.

I suppose it's possible to extend utf8 to accept a bytevector view (internally, 
an array of rank 1 and type vu8) since utf8 isn't itself a type (in the way 
you'd expect something called bytevector->xxx should be constrained to 
arguments that satisfy bytevector?). It also helps that there aren't a lot of 
functions utf8->xxx that you'd need to fix.

I hope this makes sense.

  Daniel