[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why vectors?

On Mon, 11 Aug 2008, Derick Eddington wrote:

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

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.

when/why/how would these operations be necessary or even useful, generally
speaking?  that would be akin to iterating, searching, composing, and
manipulating a C struct definition.  it just doesnt make sense.