[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Also SUBSEQ and FILL! [was Re: additional operations: COPY! and COPY]

This page is part of the web mail archives of SRFI 66 from before July 7th, 2015. The new archives for SRFI 66 contain all messages, not just those from before July 7th, 2015.



On Mon, 14 Mar 2005 sebastian.egner@xxxxxxxxxxx wrote:

> Then I would like to support and Taylor's proposal of having a COPY!
> operation, for example with the following specification:
> 
> (BYTE-VECTOR-COPY! lhs i-lhs rhs i-rhs n)
> 
>         copies n bytes from the byte-vector rhs (starting at index i-rhs) 
> into
>         the byte-vector lhs (starting at index i-lhs). The exact integers 
> n, i-rhs,
>         and i-lhs satisfy
> 
>                 0 <= i-rhs <= i-rhs + n <= (byte-vector-length rhs),
>                 0 <= i-lhs <= i-lhs + n <= (byte-vector-length lhs).
> 
>         The procedure makes sure the elements are properly copied, even if
>         lhs and rhs refer to the same byte-vector object.
> 
> (Warning to implementors in C: Use memmove, not memcpy!)
> 
> In addition, I am frequently missing VECTOR-COPY, and this will likely
> also be the case for byte vectors. So I propose to include also:
> 
> (BYTE-VECTOR-COPY byte-vector)

I'd like to suggest generalizing this to something like:

  (BYTE-VECTOR-SUBSEQUENCE byte-vector [start-offset [end-offset]])

or maybe just adding:

  (BYTE-VECTOR-SUBSEQUENCE byte-vector start-offset [end-offset])

which granted is implemented in two lines with a CREATE and a COPY!, but 
neverthess I find it a quite common operation worthy of a common name.


> Concerning the /fill/ argument in MAKE-BYTE-VECTOR: It is optional in
> R5RS, but I would be in favour of having it mandatory here.

I would like to additionally suggest:

  (BYTE-VECTOR-FILL! byte-vector start-offset end-offset(or length?) value)

for the many times I find myself needing to fill just a portion of a byte
vector.

-- 
-- Donovan Kolbly                    (  d.kolbly@xxxxxxxxxxx
				     (  http://www.rscheme.org/~donovan/