Email list hosting service & mailing list manager


Re: Why vectors? Elf 11 Aug 2008 22:29 UTC

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

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.

-elf