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
> operators.)

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.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports