Re: plist-based package.el (was Re: cl-defstruct-based package.el, now with ert tests and no external tar!)

["Stephen J. Turnbull" <stephen@xemacs.org>]

Ted Zlatanov writes:
 > On Thu, 06 Jun 2013 18:30:11 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: 
 > 
 > SJT> Ted Zlatanov writes:
 > >> plists as a sequence of odd=key and even=value don't actually associate
 > >> the key with the value, unlike hashtables and alists.
 > 
 > SJT> They do if you use plist-put and plist-get.  If you use list
 > SJT> primitives, you get what you deserve, which may not always be what you
 > SJT> want....
 > 
 > The association is positional.  All you have to do is insert an
 > element in the middle of the list and the plist is broken.

That's what I said, except more generally.  Really, one should pay
proper respect to venerable data structures.  They're often fragile.

 > Also there's no iteration primitive,

That's a bug in Emacs, not in plists as an ADT.  It would be easy
enough to add, and would be efficient (at least if written in C where
the obvious pointer-chasing algorithm is O(n), rather than in cl with
an O(n^2) algorithm!)

 > By contrast, an alist is an actual list of association cells

Actually, alists are just as bad, because neither keys nor values are
well-defined.  Key identity is ambiguous because of `assq', and value
identity is ambiguous because you don't know whether cdr or cadr (or
perhaps something more complex, such as (nth i item)) fetches the
value from the item.  If you make a mistake in your map function,
mapcar can become a weapon of mass destruction.  In a plist, on the
other hand, key and value are well-defined.

That, and the clean print representation, are why I strongly prefer
plists in APIs where the machine won't make mistakes -- once the bugs
are fixed -- but humans often have to write to that API.  Can't use a
hash table for that!  Well, you can, but interestingly enough, the
readable print representation of a hash table is built around a plist.

 > that works with `mapcar', and a hashtable is opaque so you don't
 > know or care how the association is maintained, but you can't screw
 > it up.

Aaahhhh, *hash* *tables*.  Now I like where you're headed!  An opaque
type, the modern programmer's heartthrob.  I have to agree with you
there.  "Opaque types are one honkin' great idea!  We should do more
of those."[1]



Footnotes: 
[1]  With apologies to Tim Peters.