Scheme language standardization process
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@x http://per.bothner.com/ _______________________________________________ Scheme-reports mailing list Scheme-reports@x http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports