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:26 -0700, Elf wrote: > On Mon, 11 Aug 2008, Derick Eddington wrote: > > <lotsa snip> > > 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? > > > > SRFIs have to have reference implementations. It's better when theyre usable > and reasonably efficient than when they're not. It's also possible to design > them in a clean, general fashion, rather than worrying about what kind of > compiler they have. This is especially important for ERR5RS as a point > of contrast and portability. But isn't one of the main themes of this SRFI that the R6RS's record-type-descriptor and parent-rtd are lame because sophisticated optimizing compilers don't need them because they can do compile-time flow analysis on the run-time variables to figure out optimizations (such as what Will has described elsewhere in his criticisms of the R6RS records)? With a system that does not do such flow analysis optimization, isn't there a performance concern over record constructors, accessors, and mutators? It's been my impression that this SRFI is aimed at state-of-the-art compilers, which I like, because I want technological advancement. -- : Derick ----------------------------------------------------------------