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 15:29 -0700, Elf wrote: > 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? When making your own layers on top of the ERR5RS records procedural and inspection layers, which is one of the main purposes of exposing these layers. > that would be akin to iterating, searching, composing, and > manipulating a C struct definition. it just doesnt make sense. Well, Scheme is all about code defining code and being able to build up arbitrary layers on top of layers. Why make the API's field specifiers less convenient if it's unnecessary? Why are vectors necessary for the syntax of the arguments to make-rtd and rtd-constructor? Why are vectors needed for the return values of rtd-field-names and rtd-all-field-names, when you're requesting a sequence of the field names so you can work with it? Look at the vector<->list converting done in the draft's reference implementation for an example of working with these field specifiers as lists. What if someone dreams up some really dynamic use of ERR5RS records where dynamic reflection on unknown record-types is used to dynamically generate a new record type determined by the reflection (and maybe some other inputs). I can imagine you'd want to be using lists to work with the field specifiers. -- : Derick ----------------------------------------------------------------