I think this comes down to some historical baggage around the original idea that people would just use association lists ("alists") by default, while hashtables would be an advanced feature used mainly in the optimization phase, when profiling indicated that alist lookups were a bottleneck. The alist literal is a lot friendlier:

    '((name . "andrew") (location . "sf"))

(Incidentally, you probably don't really want 'name and 'location to be strings.)

It's curious that no quasi-standard reader macro for hash literals developed, though.

I think another factor is that while the primitives for modifying readtables made it into the standard, an interface for using them in a way that limits the changes to the code you own (and not, say, additional libraries you load) is something that the users had to come up with.

It's not a lot of code or too complex to do that, but it's not obvious either and some people got it wrong or do it differently and I think that made reader modifications less common than they otherwise might have been.

I haven't looked too closely at the details but some of cl21's changes look like they might try to address this issue.

One could make the argument (I think so, at least) that if the number of associations you are dealing with is small enough to write out literally, then using a hash table is a mistake. It might be one of Common Lisp's strengths that is has ways to represent small tables efficiently and thus avoids the "hash addiction" that haunts languages where hash tables are used for everything.

But even if a more compact way of constructing hash tables is called for, why a literal syntax instead of a more compact constructor? E.g. you could write

    (dict "name" "andrew" "location" "sf")

with a compiler macro that produces exactly the above code.

Or you can write a function for it and do something like:

(let ((myhash (make-hash-table :test 'equal))) (add-hash-entry (("name" "Andrew") ("location" "sf")) myhash)

Which seems, to me, easier than having more special-case syntax to learn.

But I suspect this may be one of the drawbacks of Lisp, (indeed, it may turn out to be a problem with any powerful programming language.) It's so absurdly easy to do things like that, that incremental advances can be retarded by virtue of the steps along the way not being shared. And then when someone has to come along and use what you've written, without having been there for the steps along the way, the base level of abstraction they have to build up from is too low.

Yep! It's necessary to modify slime (or light table? I've been interested in making a CL plugin for it) to take advantage of this syntax, but the absense of sane reader macros in the spec has always driven me nuts.

Huh? No you don't... Maybe I don't get what you mean.

Here's the code for basic hashtable syntax:

https://gist.github.com/ejbs/8924773

I think this reflects one of the fallacies that people from other languages bring to Lisp. They think that all languages are more or less immutable.

If something annoys you (like funky function names) you can alias them or add whatever you think is missing to the language.

E.g. You could define second as something like

(defun second (list) (nth 1 list))

and use it forever, just as if it were in the base language.

As an example I have a function L2HT which takes a list and returns a hash table:

(l2ht '((1 "one") (2 "two)))

(You can override the hash table type with various parameters if you like).

That's two different things. The thing below is literal syntax for hash-table objects.

It's easy to add to CL, btw.