On Thu, Nov 16, 2023 at 1:23 PM Michael Heerdegen <michael_heerdegen@web.de>
wrote:

> João Távora <joaotavora@gmail.com> writes:
>
> > The only way you are eventually going to get to equal performance
> > with cl-lib's fastest variants (but only the non-destructive, of course)
> > is if you start every seq.el entry point with sth like
> >
> >    (if (sequence-p seq) (call-equivalent-cl-lib-version seq) ...)
> >
> > But then I don't see how that fits in with the cl-defgeneric,
> > which does dispatching before that if.  The only way I see this
> > is to invent a new kind of specializer in cl-generic.el like
> > 'definitely-not-sequence'.  There could be some other solution,
> > maybe Michael as a clue.
>
> I'm a bit lost I must admit.  I don't understand the use of your
> `sequence-p' test (all we use seq.el for are sequences...?).


Yes, but custom sequences don't respond t to sequencep.  It is a
C built-in that only returns t for lists and arrays and strings.
And those are the types that the sequence functions in cl-lib.el
works with, and why it is faster than seq.el, because it only
dispatches between them with ifs.  If seq.el wants to be just
as fast, it must to that much simpler kind of dispatch, and
this has of course has implications for its generic function
interface.

João