undefined | Better HN

0 pointsmjn12y ago0 comments

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.

0 comments

mcn12y ago

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.

j / k navigate · click thread line to collapse

0 comments

mcn12y ago

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

j / k navigate · click thread line to collapse