[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [External] : Re: Lift {global,local}-key-binding to Lisp
From: |
Drew Adams |
Subject: |
RE: [External] : Re: Lift {global,local}-key-binding to Lisp |
Date: |
Thu, 21 Jan 2021 18:16:32 +0000 |
> 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.
- Lift {global,local}-key-binding to Lisp, Eli Zaretskii, 2021/01/13
- Re: Lift {global,local}-key-binding to Lisp, Stefan Kangas, 2021/01/14
- Re: Lift {global,local}-key-binding to Lisp, Eli Zaretskii, 2021/01/14
- Re: Lift {global,local}-key-binding to Lisp, Eli Zaretskii, 2021/01/14
- Re: Lift {global,local}-key-binding to Lisp, Leo Liu, 2021/01/14
- Re: Lift {global,local}-key-binding to Lisp, Óscar Fuentes, 2021/01/14
- Re: Lift {global,local}-key-binding to Lisp, Eli Zaretskii, 2021/01/15
- Re: Lift {global,local}-key-binding to Lisp, Stefan Kangas, 2021/01/21
- RE: [External] : Re: Lift {global,local}-key-binding to Lisp, Drew Adams, 2021/01/21
- Re: [External] : Re: Lift {global,local}-key-binding to Lisp, Dmitry Gutov, 2021/01/21
- RE: [External] : Re: Lift {global,local}-key-binding to Lisp,
Drew Adams <=
- Re: [External] : Re: Lift {global,local}-key-binding to Lisp, Dmitry Gutov, 2021/01/21
- Re: Lift {global,local}-key-binding to Lisp, Eli Zaretskii, 2021/01/21
Re: Lift {global,local}-key-binding to Lisp, Andrea Corallo, 2021/01/14
Re: Lift {global,local}-key-binding to Lisp, Dmitry Gutov, 2021/01/15
- Re: Lift {global,local}-key-binding to Lisp, Eli Zaretskii, 2021/01/15
- Re: Lift {global,local}-key-binding to Lisp, Dmitry Gutov, 2021/01/15
- Re: Lift {global,local}-key-binding to Lisp, Eli Zaretskii, 2021/01/15
- Re: Lift {global,local}-key-binding to Lisp, Dmitry Gutov, 2021/01/15
- Re: Lift {global,local}-key-binding to Lisp, Christopher Miles, 2021/01/17