Antti Korpi

Here's what we have as of bf7bb54, shown in the REPL:  An illegal identifier occurring in a built-in macro is highlighted in source. This...

@isiahmeadows I've just had macros throw an error when user input is nonsensical. However, the compilation env makes no attempt to catch errors from macros at the moment. Hence the...

f19be373fbcba3c0fc380c2adc15d0f4e171b1f0 now catches macro errors and adds diagnostic data before rethrowing. Thanks for raising that.

The computed member expression macro is called `get`. `(get a b)`→ `a[b];` `(. a b)`→ `a.b;` It's mentioned toward the end of [the tutorial section about arrays and objects](https://github.com/anko/eslisp/blob/master/doc/basics-reference.markdown#arrays-and-objects). I...

> To do this properly, named property access needs to always be done with strings, like `(. a 'b')`, or at least with self-evaluating symbols, like `(. a :b)`. This...

Thanks so much for your thoughtful analysis. I think I see what you mean now. What you suggest is that if the `.` macro behaved such that identifiers in it...

@Gonzih I don't understand. Could you give an example?

My idea is to keep the core language very plain (so e.g. `.` means exactly a member expression, nothing else), then let user-defined macros add sugar, and make user macros...

@Gonzih It's not quite just a matter of removing `get`—there are some downsides too. I've summarised the points for and against it [here](https://github.com/anko/eslisp/pull/14#issuecomment-143376495). Do you think the tradeoff is worth...

@Gonzih The flexibility is sometimes needed. Quoting @lhorie [from chat](https://gitter.im/anko/eslisp?at=56044d40131b784f781fbb23): > Oh and another use case I just remembered is promises, which have a `catch` method. Identifiers that have the...