[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: plist-based package.el (was Re: cl-defstruct-based package.el, now w
From: |
Stephen J. Turnbull |
Subject: |
Re: plist-based package.el (was Re: cl-defstruct-based package.el, now with ert tests and no external tar!) |
Date: |
Fri, 07 Jun 2013 12:07:44 +0900 |
Ted Zlatanov writes:
> On Thu, 06 Jun 2013 18:30:11 +0900 "Stephen J. Turnbull" <address@hidden>
> 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.
- plist-based package.el (was Re: cl-defstruct-based package.el, now with ert tests and no external tar!), Daniel Hackney, 2013/06/04
- Re: plist-based package.el (was Re: cl-defstruct-based package.el, now with ert tests and no external tar!), Dmitry Gutov, 2013/06/04
- Re: plist-based package.el (was Re: cl-defstruct-based package.el, now with ert tests and no external tar!), Ted Zlatanov, 2013/06/05
- Re: plist-based package.el (was Re: cl-defstruct-based package.el, now with ert tests and no external tar!), Stefan Monnier, 2013/06/05
- RE: plist-based package.el (was Re: cl-defstruct-based package.el, now with ert tests and no external tar!), Drew Adams, 2013/06/05
- Re: plist-based package.el (was Re: cl-defstruct-based package.el, now with ert tests and no external tar!), Ted Zlatanov, 2013/06/05
- Re: plist-based package.el (was Re: cl-defstruct-based package.el, now with ert tests and no external tar!), Stephen J. Turnbull, 2013/06/06
- Re: plist-based package.el (was Re: cl-defstruct-based package.el, now with ert tests and no external tar!), Ted Zlatanov, 2013/06/06
- Re: plist-based package.el (was Re: cl-defstruct-based package.el, now with ert tests and no external tar!),
Stephen J. Turnbull <=
- opaque data types (was: plist-based package.el (was Re: cl-defstruct-based package.el, now with ert tests and no external tar!)), Ted Zlatanov, 2013/06/07
- Re: opaque data types, Christopher Schmidt, 2013/06/07
- Re: opaque data types, Ted Zlatanov, 2013/06/07
- Re: opaque data types, Christopher Schmidt, 2013/06/07
- Re: opaque data types, Ted Zlatanov, 2013/06/07
- Re: opaque data types, Christopher Schmidt, 2013/06/08
- Re: opaque data types, Ted Zlatanov, 2013/06/09
- Re: opaque data types, Stefan Monnier, 2013/06/07
- Re: opaque data types, Ted Zlatanov, 2013/06/07
- opaque data types, Stephen J. Turnbull, 2013/06/08