Re: plists, alists, and hashtables

[Robert Thorpe <rt@robertthorpeconsulting.com>]

Ted Zlatanov <tzz@lifelogs.com> writes:

> PJB> This extends easily to any other data structure for which you'd want a
> PJB> literal representation.
>
> OK, but still, I'm not interested in heaps, trees, graphs, skip lists,
> or other data structures.  I'm interested in improving the accessibility
> and popularity of hashtables in order to avoid the complexity and
> ambiguity of alists and plists when dealing with maps.

As Pascal mentioned, we only have a very small number of characters left
to use for read syntax.

You can't just consider one proposal alone.  Just because something is
useful doesn't mean that it's useful enough to burn a character or two
for.  It has to be compared to alternatives.

There may be alternatives though.  For example, instead of:
#s(hash-table size 65 test eql rehash-size 1.5 rehash-threshold 0.8 data ())

We could have a shorthand, perhaps #s(h data) .

Like Pascal I think alists are generally a good idea.  People who don't
understand the performance implications of them won't understand those
of hash-maps either.  Especially when things are done per key.

In an editor the vast majority of maps are likely to contain only a few
variables.  A few years ago I made a program that examined every Emacs
variable that ended in "alist".  Almost all of them were short.  Only a
handful were long enough to cause performance issues.

If a hash-map type were used then there could be a bit to signify if
it's *really* a hash.  I've heard that some of the scripting languages
are doing this because they've found what I found; that most maps
contain so few elements that hashing just makes things slower.  But, the
bit would have to be tested before every map operation.

BR,
Robert Thorpe