I've been programming in Lisp for, oh, less than a week.
I have a question:
Can the components of a property list for a symbol themselves be lists,
or must the components of the property list be atomic objects?
greg
Greg Something wrote:
> I've been programming in Lisp for, oh, less than a week.
> I have a question:
> Can the components of a property list for a symbol themselves be lists,
> or must the components of the property list be atomic objects?
The property names are usually symbols. The property values can be
anything at all.
When I say "are usually symbols", I mean: they *can* be anything
at all, but they are compared as if with EQ and that can lead to
implementation-dependent results with e.g. numbers; and that for
aesthetic reasons they ought to be, as it were, name-like. That
pretty much means symbols.
Many Lispers prefer to avoid property lists entirely, and use
hash tables instead.
--
Gareth McCaughan Dept. of Pure Mathematics & Mathematical Statistics,
·····@dpmms.cam.ac.uk Cambridge University, England.
Gareth McCaughan <·····@dpmms.cam.ac.uk> writes:
> Many Lispers prefer to avoid property lists entirely, and use
> hash tables instead.
I'll give you "some". I question "many".
Your remark appears to express an implicit value assignment to this
choice. I strongly disagree with any claim that if property lists went
away, nothing would be lost. Property lists and hash tables are just
different, and making an early-binding decision to use one rather than
the other consistently throughout time is a questionable approach in
my opinion.
Hash tables have the strong disadvantage that (especially for EQ hash)
the objects in them need to be rehashed on every gc OR if they are not
moved on every gc then they need to be rehashed on first access after
the gc. The latter is almost always what is done by implementations
I've seen, but the result is that people choose hash tables for some
kind of performance that isn't much slower than constant time, but
sometimes they are surprised and dismayed by the fact that a rehash
can cause them to have really a very long wait for an access. If the
application isn't in a critical interactive phase, this can be fine,
but if it is, this can be seriously annoying. (It is a design error
in Common Lisp, IMO, that one can't select whether to rehash-on-gc vs
rehash-on-access as part of the creation options for a hash table,
since the right decision is application dependent and without
individual hash-table by hash-table advice from the application, the
system cannot hope to do this right.)
Hash tables do have a data-privacy advantage that property lists do not.
But even that has a flip side because it loses the kind of debugging
simplicity that comes from being able to see a symbol's properties and
immediately leap to some conclusions that are harder to leap to if you
use hash tables.
Property lists also offer some data storage capabilities (such as
shadowing) that hash tables are incapable of.
Property lists also have the intersting property of being attached to
something that is not a container. I don't want to get into a long
explanation of why this is significant, but let me just say that I've
seen this fact exploited by myriad systems to avoid circularity problems.
Further, property lists are attached to things that print re-readably;
hash tables have no printed representation.
And finally, one might argue that property lists suffer from a worry
that a given symbol might get so many properties that GET was
inefficient, but in practice I've almost never seen that happen. The
longest property lists I've ever seen had fewer than 20 elements, and
most are in the 0-3 range, I'd bet. I'd be surprised if any hash
table lookup was faster on average than a GET... and as for worst
case, I'd be surprised if the stupid rehash-on-access GETHASH worst
case wasn't massively worse than the worst case long property list GET.
In practice, I don't think anything bad comes of using GET, and I think
much good comes of its simplicity.
I use hash tables all the time. But I also use property lists. The
right tool for the right job, I always say. Though a lot of the time,
more often than some people would like to admit, any of several ways
works just fine.
Kent Pitman wrote:
[I said:]
>> Many Lispers prefer to avoid property lists entirely, and use
>> hash tables instead.
>
> I'll give you "some". I question "many".
>
> Your remark appears to express an implicit value assignment to this
> choice. I strongly disagree with any claim that if property lists went
> away, nothing would be lost.
For the record, I didn't intend to make any such claim. (In fact,
the motivation behind my remark was something like this: "Here is
a beginner being taught about property lists. This might be because
he is being taught by a dinosaur whose ideas of Lisp are still based
on LISP 1.5 and don't include exciting modern features[1] like hash
tables. In this case, he ought to be told that hash tables exist,
and in such a way as will make it clear that they are often a
better choice than property lists".)
[SNIP: lots of sensible comments, including a number of things
I hadn't thought of]
> I use hash tables all the time. But I also use property lists. The
> right tool for the right job, I always say. Though a lot of the time,
> more often than some people would like to admit, any of several ways
> works just fine.
I wouldn't contemplate disagreeing.
(One thought occurs to me that has probably been known for years
by those who actually write a lot of Lisp. The obvious problem
with using property lists is the possibility of key-space collisions;
I don't think I've ever seen it observed that the package system
provides a perfectly acceptable way around this. I wonder whether
I've just not read the right books, or whether it's regarded as
too obvious to require comment.)
[1] Note for the humour-impaired (in which category I am not for
an instant suggesting Kent is likely to fall): obviously I don't
actually consider hash tables "exciting" or "modern".
--
Gareth McCaughan Dept. of Pure Mathematics & Mathematical Statistics,
·····@dpmms.cam.ac.uk Cambridge University, England.
Gareth McCaughan <·····@dpmms.cam.ac.uk> writes:
> (One thought occurs to me that has probably been known for years
> by those who actually write a lot of Lisp. The obvious problem
> with using property lists is the possibility of key-space collisions;
> I don't think I've ever seen it observed that the package system
> provides a perfectly acceptable way around this. I wonder whether
> I've just not read the right books, or whether it's regarded as
> too obvious to require comment.)
Well, the only data point I have is that I was going to wait for
someone to say "key-space collision" before raising the package
system, but I did in fact think of this in preparing my previous
message. So with respect to this conversation, there was already at
least one case of it seeming "somewhat obvious". Though part of that
was not really so much that I thought everyone would think of it as
that I thought it would distract from other points to be made.
Indeed, the package system is designed more or less explicitly to
solve this specific issue (among a small number of others) and so it
would be quite sad if it didn't. Macsyma, KEE, and other "big
systems" didn't port to the Lisp Machine without collision and since
the Lisp Machine was trying to be a single address space hosting
multiple complex applications (including those intrinsic to itself,
such as Zwei/Zmacs, the compiler, the various file systems, etc.), the
package system was devised to partition programs that would otherwise
clobber one another. Common Lisp (and, by historical inclusion, Lisp
Machine Lisp) is frequently criticized for having not gone with a
"module system", but a module system would not have solved these
problems. It would have been necessary to change the shape and
performance characteristics of existing programs in unpredictable ways
in order for LispM/CL to have gone with module systems. (A module
system could have been done in addition, rather than instead, and
still could be. That's an independent and more valid criticism.)
> ... I don't actually consider hash tables "exciting" or "modern".
Yes, a point I tried to make in my talk recently at this year's lisp
conference (based mostly on observing MYSELF sometimes still referring
to them as exciting and modern--sigh) was that Lisp needs to make sure
to stay on track with providing things that ARE exciting or modern.
There's a tendancy to think labels like "exciting" and "modern" are
fixed aspects of a feature. You can repeat the same old chants about
something and forget they sometimes change. Some strengths of Lisp do
continue to be strengths as time passes, but others require care and
feeding. Lisp has traditionally tried to provide facilities for
"expressing" ideas not just "implementing" them. Hash tables are
something you can implement in other languages, but Lisp assumes a
hash table is a given and so allows you to merely express your needs
for the use of a hash table, which to me gives a qualitatively
different feel. But that isn't new any more, and I hope vendors will
continue to invest in adding features to the language that ARE
exciting and modern so that Lisp can continue to lead the field in the
packaging of technology. Recently, a lot of investment has gone into
commercial Lisps to give users better access to the loads of
technology being developed in other languages. That's a good start.
What remains is (a) to make the mechanisms for external access
standard, but more importantly (b) to package those externally
accessible things [not just once but on an ongoing basis] in ways that
assure Lisp users always have a leg up in the marketplace. Too often
when a new technology comes out (whether it's X Windows or CGI or
CORBA or Java or OLE or ...) one is faced with going to the bookstore
and buying any of forty 3-inch thick books to understand how these
things work. Lisp should be providing a structural alternative, which
is to just tell you what service is provided and to actively shield
you from having to read any books about how the underlying substrate
works...
My uses of those "exciting" and "modern" terms in this context should
be seen more like as if I'd referred to "rock music" as exciting and
modern; the statement "I like rock music because it's exciting and
modern" can be true even if "rock music" is not "exciting and modern";
that is, I can like or decide or think something for a reason that is,
when examined independently as a statement on its own, factually
false. And by introspecting about these reasons, and they're creeping
falsehood, we can learn the keys to needs to be done to keep it alive,
just as music has done. One thing that makes people like certain new
music is that it's "exciting" and "modern" and you just have to figure
out what that is at any given point in order to come up with a new
trend. Same with programming languages. Another thing that makes
music good is that it has certain instrinsically aesthetic and
timeless elements; those are things you try not to lose as you jazz
things up. Same again with programming languages.
Maybe I'm belaboring a point that's really obvious, I don't know. But
then, while I see isolated action by individual vendors in different
parts of their implementation, I don't see that investment by the
community as a whole in making sure the language per se keeps pace. I
hope that is something that will come, perhaps either as the ANSI
standard comes up for renewal or else through the ALU or some other
more informal activity. But I want to be able to say that the
language has "new and exciting" features, but given that the language
is pretty static since its "feature freeze" in 1988, that's hard to
do. It's good that vendors have taken up the slack through individual
investment, but the more cross-vendor uniformity and publicly maintained
documentation there is of that, the better chance there is that such
efforts will have longevity.