[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] bytevector/string/vector comments
On 01/09/2012 02:25 PM, John Cowan wrote:
>> Should perhaps have string-copy!, presumably compatible with SRFI-13.
>> Should perhaps have vector-copy!, presumably compatible with SRFI-43.
> I think the feeling is that bytevectors will often be used for buffers
> and such, and that partial and destructive copy operations are needed
> for them but not for the basic types list, string, and vector. (Per
> contra, bytevectors don't get mapping functions or general conversion
To my thinking, there are few semantically-meaningful uses of fixed-size
mutable vectors or strings. Fixed-size mutable vectors or strings are
useful primarily because they map inexpensively to hardware, and have
two primary uses (that I can think of off-hand):
(1) An expandable buffer: You read or otherwise generate data that
gets appended to the buffer; when the buffer is full, you allocate a
bigger buffer. For this use-case you need to copy the data in the old
buffer over to the new buffer.
(2) A buffer as a window into a larger sequence. You might want to
insert a string at the "current position" which requires a copy operation.
Regardless, copying a slice from one vector/string into another is
such a fundamental operation that it should be added, IMO, considering
that it's tedious to write if "by hand", and that a standard library
routine is likely to be much more efficient (especially for strings,
since that avoids the need for boxing+unboxing the characters).
One could also argue that "character" operations don't really make
semantic sense in a Unicode world, and so string-set! has limited
usefulness. Thus string-copy and string-copy! are the actual
useful "primitive" operations.
>> (At least if bytevector-vector! is provided.)
> I'm not sure what this sentence means.
I meant try write bytevector-copy! - i.e. if bytecode-copy!
(or bytevector-copy-partial!) are standardized, we should
also standardize vector-copy! and string-copy! for consistency.
>> string-copy should perhaps have 3-operand option, compatible with
>> SRFI-13 and vector-copy.
> The WG voted back in ballot 1 (#64) to provide vector-copy "as in SRFI
> 43" without actually noticing that SRFI 43 vector-copy provides start,
> end, and fill arguments. I did notice at the last minute for draft 5,
> and added the cases -- with ticket #310 to cut the small language back
> to a simple copier.
Well, I suspect vector-copy! has more uses that vector-fill!
>> bytevector-copy-partial should be called bytevector-copy for
>> compatibility with vector-copy.
> The WG specifically voted in ballot 3 (#205) to keep bytevector-copy and
> bytevector-copy-partial separate.
I think that was a mistake, in lieu of the prior art of SRFI-43.
I also think the shorter names are better regardless.
Scheme-reports mailing list