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

[Eli Zaretskii]

> From: Alex Gramiak <address@hidden>
> Cc: address@hidden
> Date: Sat, 20 Apr 2019 12:18:01 -0600
> 
> 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?).

What would be the advantage of that vs lists?

> >> > As for speed, did you have any application where the speed of the Lisp
> 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.

You mean 'member', right?  I don't think 'memq' checks 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.

Vectors are used quite rarely in Emacs Lisp, IME.  I think we should
all keep in mind that Emacs Lisp is not a general-purpose language, it
is a language for implementing and extending Emacs.

> 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.

Every additional primitive means a burden.  More importantly, we
should IMO be consistent in how we design and implement families of
functions, which is why I still think we should extend seq.el
(possibly some of that with internal C primitives, if needed), instead
of starting a new family.