On 24 Sep 2009, at 4:21 am, Michael Lenaghan wrote: > >> I am not saying blobs are *defined* in terms of general vectors, >> not at >> all. I am saying that on systems with no native blobs, general >> vectors >> can be used to (crudely, but correctly) *emulate* blobs. Once you >> have >> blobs, SRFI-4 vectors are easy. > > Yes, and I'm saying that a naive implementation with > define-vector-type might implement all or most vectors in terms of > general vectors--but that choice would be hidden behind an abstraction > boundary. A more sophisticated implementation would be free to take > advantage of the boundary. > > So in a sense we don't disagree on this point. >
Yes, what you suggest is a logical generalisation of SRFI-4. I just don't think it needs to be in the core. In the core, however, it could be explained that an operation that reads a bunch of bytes from a binary port returns a vector of bytes - but that vector must not be modified, which would then free up implementations to just return general vectors that happen to be full of small exact integers, or to actually return a specialised srfi-4- esque 8uvector; if the vector-ref operation is genericised to handle homogenous vectors transparently, that'll get you the behaviour required by the spec along with the performance and compactness made possible by homogenous vectors. ABS -- Alaric Snell-Pym Work: http://www.snell-systems.co.uk/ Play: http://www.snell-pym.org.uk/alaric/ Blog: http://www.snell-pym.org.uk/archives/author/alaric/ _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
