Re: [RFC] Some new vector procedures (vector-{memq, apply, to-string, ...})

[Alex Gramiak <agrambot@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

> Isn't seq-position the equivalent of vector-index?

It's quite similar (I forgot that it took an optional predicate), though
seq-position takes a 2-arg procedure that's supposed to check for
equality, while vector-index takes a 1-arg procedure. One can implement
one in terms of the other.

> Anyway, if some algorithms are missing from seq.el, maybe we should
> just add them there instead of starting an entirely new family of
> primitives?

Ideally. Though in the case of vector-partition the size of the 2
partition vectors is not known in advance, so a Lisp implementation
would have to create two extra Lisp vectors as opposed to using
SAFE_ALLOCA. That is, unless Elisp grows a growable/resizeable vector
type (which is something I was thinking about -- would that be denied?).

>> > As for speed, did you have any application where the speed of the Lisp
>> > implementation was inadequate?
>> 
>> For vector-memq, the Lisp implementations almost disallow it from being
>> used over memq/lists. The equivalent in seq.el, seq-position, is ~100x
>> slower for smaller vectors and ~200x for larger (500 elements) vectors.
>
> The factors don't really answer my question.  The question was whether
> some real-life application that uses seq.el is so slow that moving
> them to C is necessary.  IOW, the question was about absolute times,
> not relative times.  If you can describe such use cases, I'd like to
> discuss them with the participation of seq.el's maintainer first.

Currently the only (M)ELPA package I use that depends on seq is
Flycheck, that doesn't seem to use seq with vectors.

>> The main two I care about here are vector-memq/vector-member.
>
> Please tell why in more detail.

Well, it's a stupid itch, but sometimes I see the (memq elt <list
of constants>) and think that using a vector would be faster/better,
mainly since memq has to check for cycles. More generally, there's
currently no way to check existence in a vector nearly as fast as one
can check existence in a list, which is unusual in programming
languages. This unfairly discourages usage of vectors in appropriate
places.

I don't believe that the vector-memq/member procedures would pose a
maintenance burden like some of the others (vector-apply in particular)
would.