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

[Eli Zaretskii <eliz@gnu.org>]

> From: Alex Gramiak <agrambot@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 20 Apr 2019 19:52:36 -0600
> 
> > Vectors are used quite rarely in Emacs Lisp, IME.
> 
> Not enough suitable vector procedures doesn't help, though. Emacs Lisp
> is certainly not a general-purpose language, but that doesn't mean that
> it has to be missing particular language features/types that improve
> efficiency as long as it doesn't add a lot of complexity.

I actually think it means precisely that: we don't need to expand the
language just because some feature is missing, we should do that only
if said feature is important for implementing Emacs features.  The
dynamic nature of Emacs on the one hand, and the efficient
implementation of lists OTOH, are the main reasons why vectors are
rarely used in ELisp programs.  I think most of the uses are for
objects whose structure and size are known in advance, and for objects
that are read-only from the Lisp side.  When we needed a vector-like
object that could change its structure dynamically, we invented
char-tables.

> > 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.
> 
> I'm not sure what you mean here by internal C primitives if it's not
> similar to vector-memq/member. Do you just mean expose a single
> `sequence-memq' and keep the new type-specific implementations internal?

When a C implementation is justified, yes.

Anyway, I think I spoke enough about this.  I will now let Nicolas and
others to chime in.

Thanks.