Re: plists, alists, and hashtables

[Barry Margolin <barmar@alum.mit.edu>]

In article <87oailbn8t.fsf@lifelogs.com>,
 Ted Zlatanov <tzz@lifelogs.com> 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 
function.

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, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***