[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC] Some new vector procedures (vector-{memq, apply, to-string, ..
From: |
Eli Zaretskii |
Subject: |
Re: [RFC] Some new vector procedures (vector-{memq, apply, to-string, ...}) |
Date: |
Sat, 20 Apr 2019 22:11:10 +0300 |
> 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.
- [RFC] Some new vector procedures (vector-{memq, apply, to-string, ...}), Alex Gramiak, 2019/04/19
- Re: [RFC] Some new vector procedures (vector-{memq, apply, to-string, ...}), Eli Zaretskii, 2019/04/20
- Re: [RFC] Some new vector procedures (vector-{memq, apply, to-string, ...}), Alex Gramiak, 2019/04/20
- Re: [RFC] Some new vector procedures (vector-{memq, apply, to-string, ...}), Eli Zaretskii, 2019/04/20
- Re: [RFC] Some new vector procedures (vector-{memq, apply, to-string, ...}), Alex Gramiak, 2019/04/20
- Re: [RFC] Some new vector procedures (vector-{memq, apply, to-string, ...}),
Eli Zaretskii <=
- Re: [RFC] Some new vector procedures (vector-{memq, apply, to-string, ...}), Alan Mackenzie, 2019/04/20
- Re: [RFC] Some new vector procedures (vector-{memq, apply, to-string, ...}), Óscar Fuentes, 2019/04/20
- Re: [RFC] Some new vector procedures (vector-{memq, apply, to-string, ...}), Paul Eggert, 2019/04/20
- Using SMALL_LIST_LEN_MAX for memq and list_length (was: [RFC] Some new vector procedures (vector-{memq, apply, to-string, ...})), Alex Gramiak, 2019/04/20
- Re: [RFC] Some new vector procedures (vector-{memq, apply, to-string, ...}), Alex Gramiak, 2019/04/20
- Re: [RFC] Some new vector procedures (vector-{memq, apply, to-string, ...}), Eli Zaretskii, 2019/04/21
- Re: [RFC] Some new vector procedures (vector-{memq, apply, to-string, ...}), Stefan Monnier, 2019/04/21
- Re: [RFC] Some new vector procedures (vector-{memq, apply, to-string, ...}), Alex Gramiak, 2019/04/21
- Re: [RFC] Some new vector procedures (vector-{memq, apply, to-string, ...}), Stefan Monnier, 2019/04/21