> And are pairs going to be vectors of length 2 and type Object? > If not, why not?
The more general answer: all abstractions introduce trade-offs, and we're looking for different properties in "pairs". For example, we want to present chains of pairs differently when we write them. The more specific answer: pairs introduce a different abstraction: they're a *general* vector type with a *fixed* length, not a *fixed* vector type with a general length. Those two things are orthogonal. > Okay. In that case, what is the point of primitive typed vectors? > General vectors can do everything that primitive typed vectors can do > by virtue of their expressiveness, and if you want effective specialized > vectors, they have to be done using implementation hacks anyhow. > ... > I don't see why Schemes want vectors of arbitrary fixed type. They save > neither space nor time. Er, no. First, there are only so many tag bits in a word; then you might have to follow a pointer to a structure. If you have a homogeneous vector an implementation might be able to store, say, unboxed floats directly rather than using a vector of pointers to floats. A vector of booleans might be able to pack more booleans per machine word. A vector of, say, shape records might be able to store the records directly rather than pointers to records. These things would all be invisible to the developer, but they'd all affect time and space. Second, if an implementation knows, for example, that a vector only contains floats then the garbage collector can take advantage of that in various ways. It would know, for example, that it doesn't have to walk the vector during garbage collection. (That's rather significant if you're talking about a vector with a million elements!) That's a simple example; there are more complex ones. > 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. > Not at all. It's far from clear that implementations can do growable > vectors better than a Scheme programmer can with existing powers of > procedural abstraction and syntactic abstraction, plus the new (but very > widely implemented) power of datatype abstraction with SRFI 9. Implementations can, for example, skip certain type checks in certain cases *even when running or producing safe code*. A developer working on top of the implementation can't. And, again, the ability to work directly with the memory management model (including the garbage collector) can provide substantial benefits not available to a developer. _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
