http://www.gnu.org/software/emacs/manual/html_node/elisp/Plists-and-Alists.html gives some supposed differences between plists and alists. Basically it comes down to:
- Alists can be used as stacks, where values are updated by adding a cons cell, allowing to restore previous values by deleting the topmost cons cell.
- Plists are faster for storing information about symbols because they are typically short compared to storing everything (for all symbols) in a single alist.
The first point makes sense. While the implementation of plist-get
allows using plists in such a stack-like manner, by adding new values with
(push VALUE PLIST)
(push KEY PLIST)
removing such a pair would be more involved compared to alists where one can just write
(setq ALIST (delete (assq KEY ALIST) ALIST))
though even that could be changed by defining a function for it.
The second point however seems incorrect too me, as the same advantage would apply for alists, if there was a symbol-alist
function instead of symbol-plist
. Additionally, in my experience plists are typically a bit slower than alists of the same size.
Hence I was wondering why emacs uses both conventions for storing key-value pairs, when using one would suffice.
Clarification Since it was raised in the comments: It seems largely a historical issue (emacs lisp was able to do both well, so people did both), but I'd still be interested in whether there was some rationale in the development of emacs to include builtin functions for handling both. Of course my view may be strongly colored by the Zen of Python (13th line) here to even raise the question.
nil
. But I think asking why Emacs has both isn't a good question. It has both because you can create both usingcons
function. Emacs simply deals with consequences of this feature.