[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bytevector-string-ref
From: |
lloda |
Subject: |
Re: bytevector-string-ref |
Date: |
Thu, 22 Dec 2022 13:24:21 +0100 |
> 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
- Re: bytevector-string-ref, (continued)