Re: plists, alists, and hashtables

[Ted Zlatanov]

On Wed, 05 Aug 2015 20:40:21 +0100 Robert Thorpe 
<rt@robertthorpeconsulting.com> wrote: 

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

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

OK, I understand your viewpoint.  My goal is not to burn characters but
to make it easy to create a map in ELisp.

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

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

That's all right, but I would probably prefer a Unicode pair of
characters.  In 2015, that's going to inconvenience very few people.

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

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

I see what you mean. The benefit to the users who use a hypothetical new
map syntax would be mostly code readability, because alists and plists
are not as readable as a true map syntax.  Is that enough to justify it?
If it's not obtrusive and doesn't burn reader characters, I think so.

So as a first cut, maybe «(k1 . v1) (k2 . v2)» and ««(k1 . v1) (k2 .
v2)»» would be a good syntax (equal and eql versions respectively),
simply converted to the appropriate #s(hash-table ...) syntax?

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

I think the bit check performance penalty would be insignificant, and
that the backend implementation can adapt to use lists for small maps.
In any case, using these would be voluntary, people can still use the
usual alists and plists.

Ted