Tab Atkins Jr.

Ah, kk. I disagree with the design, but at least it can be worked around. > In JavaScript, a.b does the same as a["b"], so I think it's logical that...

Yeah, I'm happy to do a review. ^_^

> So to distinguish computed access from static access, we really do need 2 separate macros. No we don't, and the current design already conflates them heavily _anyway_; the distinction...

`(. a b)` should compile to `a[b]` at all times - you're clearly invoking the variable `a` and the variable `b`, and any other interpretation is confusing. (Put another way,...

Ah, that's an interesting objection. In that case, how about everything always desugars to brackets, except self-evaluating symbols (`:b`) desugar to dot-access (and throw an error if they can't, so...

JS has "just strings and identifiers" because it has _syntax_ that lets it provide special rules for how to interpret them in different circumstances; that's how it can get away...

Quote is fine, yeah. In "real lisp" it causes the value to be of type SYMBOL, same as `:b` would. I'm not sure how that allows you to avoid adding...

Valid JSON can be done separately via a `(json)` function; that can limit values to valid JSON values, and invoke a "jsonify" contract for values that aren't valid JSON.

There are a lot of functions similar to this in Lisp, where you have a bunch of key/value pairs, some of which can have different syntax. They all work by...

It doesn't _need_ to, necessarily; leaving out the value is equivalent to setting it to `undefined`. But it is probably good to be consistent?