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
----------------------------------------------------------------