Email list hosting service & mailing list manager

Re: Why vectors? Derick Eddington 11 Aug 2008 23:32 UTC

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