On Mon, 2008-08-11 at 00:38 -0700, Elf wrote:
> On Sun, 10 Aug 2008, 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?
>
> Vector referencing is in constant time.  List referencing is in linear time.
> Vector mutation is in constant time.  List mutation is in linear time.
>
> As records are essentially vectors (constant sized, fixed order, etc) with
> procedures mapping to indices, using lists would be a significant performance
> cost for no benefit: one generally doesn't iterate over the elements of a
> record.  Record types are for grouping related *but independently used* data
> together.

I'm suggesting lists be considered for make-rtd's and rtd-constructor's
fieldspecs arguments and for rtd-field-names' and rtd-all-field-names'
return values not to assist iterating over the elements of a record but
to assist iterating over, searching, composing, and manipulating the
API's field specifiers.

--
: Derick
----------------------------------------------------------------