Hi,
I'm trying to use p-lists in common lisp but i can't find the functions
that allow to use them.
thanks in advance for any advice you can give to me.
--
BEAULIEU Fr�d�ric
·········@iname.com
Licence Informatique 2000-2001
In article <·················@iname.com>,
Frederic Beaulieu <·········@iname.com> wrote:
>I'm trying to use p-lists in common lisp but i can't find the functions
>that allow to use them.
What happened when you looked in the index of CLTL2 for "plist" or
"property list"?
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Frederic Beaulieu wrote:
>
> Hi,
>
> I'm trying to use p-lists in common lisp but i can't find the functions
> that allow to use them.
A session with ACL, "USER(n):" is the prompt:
USER(2): (setf (get 'aa 'prop2) 12)
12
USER(3): (describe 'aa)
AA is a SYMBOL.
It is unbound.
It is INTERNAL in the COMMON-LISP-USER package.
Its property list has these indicator/value pairs:
PROP2 12
USER(4): (get 'aa 'prop2)
12
--
Frederic Beaulieu wrote:
>
> Hi,
>
> I'm trying to use p-lists in common lisp but i can't find the functions
> that allow to use them.
>
> thanks in advance for any advice you can give to me.
May I quote Norvig�s book (p. 75-76)?:
"Property lists have a long history, but they are falling out
of favor... There are 2 main reasons.. First, because symbols
and their property lists are global... Second, property lists
are messy..."
Perhaps we could hear some dissentient opinions...?
---------------------
Jose-Luis Perez-de-la-Cruz
ETSI Informatica
POB 4114
MALAGA 29080 SPAIN
Tlf +34 952 132801
Fax +34 952 131397
--------------------
"J.L. Perez-de-la-Cruz" <·····@lcc.uma.es> writes:
> Frederic Beaulieu wrote:
> >
> > Hi,
> >
> > I'm trying to use p-lists in common lisp but i can't find the functions
> > that allow to use them.
> >
> > thanks in advance for any advice you can give to me.
>
> May I quote Norvig�s book (p. 75-76)?:
> "Property lists have a long history, but they are falling out
> of favor... There are 2 main reasons.. First, because symbols
> and their property lists are global... Second, property lists
> are messy..."
>
> Perhaps we could hear some dissentient opinions...?
I haven't looked, but sight unseen I believe Norvig speaks there of a
symbol's property list. The property list data structure can also be
created in other situations that do not suffer this problem and are
still quite handy as cheap alternatives to hash tables.
There's nothing really wrong with the data structure of a plist; but
the plist of a symbol is used less and less in modern code, I agree.
More often I see hash tables used instead...
In article <···············@world.std.com> on Thu, 29 Mar 2001 20:16:39
-0600, "Kent M Pitman" <······@world.std.com> wrote:
> The property list data structure can also be
> created in other situations that do not suffer this problem and are
> still quite handy as cheap alternatives to hash tables.
What about alists? What are the performance and flexibility tradeoffs
between choosing a plist and an alist?
--
-> -/- - Rahul Jain - -\- <-
-> -\- http://linux.rice.edu/~rahul -=- ·················@usa.net -/- <-
-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.220020101.23.50110101.042
(c)1996-2000, All rights reserved. Disclaimer available upon request.
"Rahul Jain" <·····@rice.edu> writes:
> In article <···············@world.std.com> on Thu, 29 Mar 2001 20:16:39
> -0600, "Kent M Pitman" <······@world.std.com> wrote:
>
> > The property list data structure can also be
> > created in other situations that do not suffer this problem and are
> > still quite handy as cheap alternatives to hash tables.
>
> What about alists? What are the performance and flexibility tradeoffs
> between choosing a plist and an alist?
I think if you analyze the number of link-follows you have to do in a plist
and in an alist, you'll find they compare similarly performance-wise.
The reason you see plists used more often than alists is probably that there
are (for historical, not technical reasons) assignment operators for plists
but not for alists.
However, if you ignore the absence of SETF of ASSOC and assume you can easily
write the equivalent, I find the difference between alists and plists for
the "discriminating buyer" to be a trade-off between what I think of as
"privacy" and "restartability".
"What on earth is he talking about?" you should be asking just about now.
Well, my point is that a "success" in a plist search gives you back the
tail of the plist in order to give you setf-able access to the cell.
That is, in (A B C D E F), finding the C tag means getting the tail
(D E F) since you can read or set the car of that. But an incidental
property of that datastructure is that you can "continue the search". So
if you write a program that returns this cell, it incidentally returns
something that can be used to restart the search.
In an alist, the equivalent structure is ((a . b) (c . d) (e . f)) and
the cell you get back is (c . d). This isn't restartable. It is, however,
"private". (And you might also say "textually brief", too.)
It doesn't accidentally reveal data that belongs to someone else
(or that is "simply irrelevant").
Often, it just doesn't matter. (And in most such cases, the set of available
operators probably causes plists to win out.) But I think both restartability
and privacy can be useful occasionally, and so it's wise to keep these two
in mind.
As an aside, I've done a fair amount of work in the MOO language, which is
similar to Lisp in some ways, but has some interesting differences. It uses
a combination of user code (which is slow and interpreted) and system
primitives (which are super-fast, not interpreted). In that environment,
I often use a data structure that I've come to call an "i-list" (indexed list),
which really makes huge computational sense there for various reasons (to do
with the fact that POSITION is super-fast compared to a user-written loop
needed to peruse an alist or plist. In CL, you don't get the huge bias in
speed but the structure may sometimes be still useful: It's
(#(a c e) . #(b d f))
If you use adjustable vectors with fill pointers, these are pretty easy to
make. But the idea is that you use position to find the index, and then read
the value out of the second element. It saves having to cdr past data and
allows you to direct-index the data once you've made it. But it can't be
simulated easily with lists because you'd still have to cdr down the second
list a second time. I recently had an occasion to make this structure to good
advantage in a program that wanted to cons little temporary plists and then
dispose of them. Being able to just reset the fill-pointer to 0 means no
consing, which you don't get from either alists or plists...
Kent M Pitman <······@world.std.com> writes:
> Well, my point is that a "success" in a plist search gives you back the
> tail of the plist in order to give you setf-able access to the cell.
> That is, in (A B C D E F), finding the C tag means getting the tail
> (D E F) since you can read or set the car of that. But an incidental
> property of that datastructure is that you can "continue the search". So
> if you write a program that returns this cell, it incidentally returns
> something that can be used to restart the search.
I'm not sure I understand. What's being used to get the tail of the
list (A B C D E F)? Member will have problems with lists that have
common keys and values, e.g., (A C C D E F), which wouldn't come up
traversing an association list, using member with :key #'car. Am I
not thinking of an obvious function, or is this an uncommon situation
in practice?
If the alternative is to use loop with destructuring-bind, there's the
difference of only a couple of parentheses and a dot (I think) between
a property list and association list.
--
Rob St. Amant
·······@haeckel.csc.ncsu.edu (Robert St. Amant) writes:
>
> Kent M Pitman <······@world.std.com> writes:
> > Well, my point is that a "success" in a plist search gives you back the
> > tail of the plist in order to give you setf-able access to the cell.
> > That is, in (A B C D E F), finding the C tag means getting the tail
> > (D E F) since you can read or set the car of that. But an incidental
> > property of that datastructure is that you can "continue the search". So
> > if you write a program that returns this cell, it incidentally returns
> > something that can be used to restart the search.
>
> I'm not sure I understand. What's being used to get the tail of the
> list (A B C D E F)? Member will have problems with lists that have
> common keys and values, e.g., (A C C D E F), which wouldn't come up
> traversing an association list, using member with :key #'car. Am I
> not thinking of an obvious function,
Yes (for a certain value of "obvious"):
(get-properties '(a b c d e f) '(c))
=> C, D, (C D E F)
Not to mention (loop for (ind . tail) on '(a b c d) by #'cddr do ...)
> or is this an uncommon situation in practice?
Probably. But there are cases involving shadowed values where it does
come up.
> If the alternative is to use loop with destructuring-bind, there's the
> difference of only a couple of parentheses and a dot (I think) between
> a property list and association list.
Well, you're never far from this view, of course.
"Rahul Jain" <·····@rice.edu> writes:
> In article <···············@world.std.com> on Thu, 29 Mar 2001 20:16:39
> -0600, "Kent M Pitman" <······@world.std.com> wrote:
>
> > The property list data structure can also be
> > created in other situations that do not suffer this problem and are
> > still quite handy as cheap alternatives to hash tables.
>
> What about alists? What are the performance and flexibility tradeoffs
> between choosing a plist and an alist?
In addition to the points raised by Kent M Pitman, there's another
dual-use aspect to plists that sometimes make them win out against
alists, and that's the duality between plists and keyword argument
lists: You can pass a plist to a function, "exploding" it into
arguments on the way, just via apply. Additionally, you can manually
destructure a plist using destructuring-bind, which again you can't
easily do with alists.
To me, alists are an opaque data-structure that has similar uses to
hash-tables, whereas plists are more transparent data-structures that
a number of CL facilities know how to handle out of the box.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein