Re: Why vectors? Derick Eddington 11 Aug 2008 21:50 UTC
On Mon, 2008-08-11 at 09:29 +0200, Per Bothner wrote: > Derick Eddington wrote: > > Why are vectors and not lists used for make-rtd's and rtd-constructor's > > fieldspecs arguments and for rtd-field-names's and rtd-all-field-names's > > return values? Is the only reason to follow R6RS's use of vectors? If > > so, I request lists be used instead because they're easier to deal with, > > as shown by how much list<->vector conversion is done in the ERR5RS > > reference implementation itself. Using lists instead would increase the > > appeal of this SRFI to me, and I think to others also. IMO, > > interoperating with the R6RS records procedures that deal in vectors > > without having to convert list<->vector is not a good enough reason > > compared to the benefit of using lists with one's primary record system > > of use, because interoperating at the procedural level where these > > vectors matter will be rare (I imagine). Or is there a good reason to > > use vectors? > > Well, of course performance-wise vectors are much more efficient than > lists as a general rule, but it mostly matters for either freequently- > accessed or long-term-retention sequences. Clearly, the internal data > structures used to represent classes should be vectors. In that case, > it can be more efficient to have reflective operations also return > (immutable) vectors - at least if return sequences can be the same > as the internal sequences. I've been assuming the internal data structures of records would not need to be less efficient in order to use lists for make-rtd's and rtd-constructor's fieldspecs arguments and for rtd-field-names' and rtd-all-field-names' return values. Having lists be used instead isn't a big deal to me, and I'm being the Devil's advocate about this because I want to make sure there's really a compelling reason to use vectors for the API's field specifiers instead of the more natural and convenient (to me, at least) lists. make-rtd and rtd-constructor will be used infrequently enough (right?) that there's not really a performance concern over having to convert a list fieldspecs argument into whatever is needed, is there? The current draft's make-rtd fieldspecs argument already requires processing because of its syntax, right? If rtd-field-names can directly return an internal data structure, that's obviously going to be the most efficient, but will it be able to or should it do that? Is it really a performance concern? Implementations of rtd-all-field-names will probably use rtd-field-names, so rtd-all-field-names' performance will be affected by rtd-field-names, but is it really a concern? What is an example where the efficiency of using vector field specifiers versus list field specifiers for the API matters? rtd-accessor and rtd-mutator take a field name symbol argument (I like that) instead of a numeric index like R6RS does, and that seems like a similar performance concern which might not really need to be a concern. What could a sophisticated optimizing compiler do for these six procedures? Thanks, -- : Derick ----------------------------------------------------------------