[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: plists, alists, and hashtables

From: Barry Margolin
Subject: Re: plists, alists, and hashtables
Date: Wed, 05 Aug 2015 15:30:07 -0400
User-agent: MT-NewsWatcher/3.5.3b3 (Intel Mac OS X)

In article <address@hidden>,
 Ted Zlatanov <address@hidden> wrote:

> I think these details are easily optimized at the C level. Clearly an
> alist is better as the *backend* hashtable implementation for up to 10,
> possibly up to 100 entries (depending on caching, pipelining, hashing
> function, and other factors). But the frontend presentation is what I'm
> concerned about. I think a better reader syntax for hashtables would
> make them easier to write and read in code and would error out if they
> are malformed. That's an improvement over alists and plists I think.

IIRC, at one time Symbolics had an implementation of Common Lisp 
hashtables that chose different internal representations depending on 
various attributes of the table, like the current size and equivalence 

But I think they got rid of this because there were bugs that occurred 
as a result of the table changing reps on the fly, and I guess they 
discovered that it didn't really buy that much in performance. For 
instance, the break-even point for alists is probably pretty low, and 
hash tables tended to be used for large tables.

Of course, that was before languages like Perl, PHP, and Javascript 
popularized the idea of using small hash tables to implement structures.

Barry Margolin, address@hidden
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

reply via email to

[Prev in Thread] Current Thread [Next in Thread]