>> (define-vector-type <name> <type>) > > Could you specify a bit more about what information <type> > should carry? > > I suspect that, to give enough information to allow "a smart > compiler" to work with this definition, you need a structured > way to define and construct types, including specifying allowed > value ranges and possible coercion rules. > It is interesting path to go, but I think resulting language > would be much more type-centric than existing Scheme. > > If you don't put enough information in <type>, then each > smart compiler need to work out the characteristics of > each type by its own, and define-vector-type doesn't help > much here. It only benefits naive implementations, in > which type-specific APIs are trivially generated even > from underspecified define-vector-types.
First, let's imagine that each type has a "container?" predicate; if "container?" returns #t then the garbage collector has to walk instances of the type and if it returns #f it doesn't. Right off the bat the vector type inherits the same predicate--the same value. An implementation can use that information to make memory management and/or garbage collection much more efficient. For programs that deal with, say, large vectors of numbers that would seem to be an easy and very important win. Second, let's say that each type knows whether or not the value can be unboxed to a native representation. The interface might be "unboxable?", "unbox", "box", "make-unboxed-vector", "unboxed-length", "unboxed-ref", "unboxed-set!". Then if "unboxable?" is true: (make-<type>-vector n): (make-unboxed-vector <unboxed-type> n) (<type>-length v): (unboxed-length v) (<type>-ref v i): (box (unboxed-ref v i)) (<type>-set! v i x): (unboxed-set! v i (unbox x)) Of course, the "unboxed" routines would most likely come from the underlying implementation--C arrays or Java vectors or such. Boxing and unboxing may or may not be worth the cost; each implementation would have to decide for itself. The point, though, is that each implementation *could* decide; someone working on top of the implementation couldn't. (No doubt there are other such examples--like leaving values boxed but packing them in some way.) > Besides, the similarity of strings and vectors are superficial; > both are fixed length and has -ref and -set! in RnRS, but > the usage pattern and the nature of their elements are very > different, so their implementations tend to differ a lot. > How do you express those difference in define-vector-type? > If you don't, then again, define-vector-type is useless > for any implementation that wants to be a bit smarter than > naive implementation where it just uses a ucs4 array as a string. I think the opposite is true. If the compiler knows that it can use a more efficient representation and implementation for "vectors of char" then define-vector-type allows it to do so. Indeed, that's the very point of the abstraction! But perhaps you meant something else? _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
