Antti Korpi
Antti Korpi
@tabatkins In that case, I must have completely misunderstood. To be maximally clear, what forms do you think should compile to `a.b`, `a[b]` and `a["b"]`?
@tabatkins > `(. a "b")` should compile to `a.b` for every string for which that is valid, and to `a["b"]` otherwise. That's the problematic part. For this reason— > for...
> to my knowledge the current state is to use `(. a b)` basically in the same way as `(.-b a)` in cljs, i.e. _always_ compile to `a.b;` and `(get...
I'm really warming up to @lhorie's `quote` suggestion: - It would address @tabatkins' very valid concerns about predictability. - It doesn't require adding any new AST types or macros. -...
Reopening to clarify that the proposed solution hasn't yet been implemented.
@impinball Yep, that's the plan; @lhorie [outlined it similarly before](https://github.com/anko/eslisp/issues/13#issuecomment-143901511) too. The issue blocking me from doing this right away is that currently `'foo` compiles to the wrong value when...
@impinball Ambiguity: Does `(var a b)` compile to `var a = b;` or `var a, b;`?
@impinball Many thanks for [the summary](https://github.com/anko/eslisp/issues/23#issuecomment-146714136). That'll make a useful base for tests.
> No, this is consistent with the planned changes to the `(.)` macro. :point_up: Correct. Sorry, the confusion is my fault. #13 should have been marked open. We had some...
Trying to isolate the root issue—correct me if I'm wrong: You want to evaluate `(+ 1 2 3)` at compile-time, such that its output (`6`) is inserted into the output...