RE: [External] : Re: Lift {global,local}-key-binding to Lisp

[Drew Adams <drew.adams@oracle.com>]

> The recent `length-<' etc. additions come to mind...
> 
> Not sure this is a good example.
> 
> length-< needs to be as fast as length to be generally useful.

The _point_ of adding those functions was to not
pay a performance penalty with a long list, just
to compare its length with some number.  IOW,
short-circuit traversing the _entire_ list, as
soon as the comparison question can be answered.
Like using `or' or `and': test only as much as
you need.

That's the _only_ performance that matters here;
it's the reason that everyone got excited about
creating these predicates.

The case for such a comparison where the entire
list actually has to be traversed is essentially
a corner case.  That was not the point of adding
these predicates.

Besides that, no info was presented on just how
much faster a C traversal of an entire list is.

Is that (unpresented) additional speed, for an
entire traversal, actually needed?  How so?

Or was the eagerness to do this in C only that:
an eagerness to do it in C?

___

Beyond that, the Lisp definitions (I provided)
are superior, in that (1) they are consistent
(not sometimes raising an error and sometimes
not, for the same predicate sexp) and (2) they
work also for dotted lists (and circular lists).

#2 means you don't have to also check a list
first, to ensure that it's a proper list before
making a comparison.  (And that extra check is
not free.)

And it means, obviously, that you get the added
benefit of being able to use the check on a
dotted list.  In Lisp, a "list" can be either
dotted or proper/true.  Both are used, and both
are useful.  If a length predicate is useful
for a proper list it can be just as useful for
a dotted list.

But Lars, who implemented the C versions, never
replied about the Lisp versions I offered.  He
just pushed the C code and passed over the Lisp
proposal in silence.  NIH?  Oh well.