This page is part of the web mail archives of SRFI 99 from before July 7th, 2015. The new archives for SRFI 99 contain all messages, not just those from before July 7th, 2015.
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 ----------------------------------------------------------------