JS syntax future-proofing, Macros, the "Reader" (was: Performance concern with let/const)

[Brendan Eich]

Waldemar Horwat wrote:
> On 09/18/2012 09:47 AM, Brendan Eich wrote:
>> 2. Tim Disney with help from Paul Stansifer (Mozilla grad student 
>> interns) have figured out how to implement a Reader (Scheme sense) 
>> for JS, which does not fully parse JS but nevertheless correctly 
>> disambiguates /-as-division-operator from /-as-regexp-delimiter. See
>>
>> https://github.com/mozilla/sweet.js
>>
>> This Reader handles bracketed forms: () {} [] and /re/. Presumably it 
>> could handle quasis too. Since these bracketed forms can nest, the 
>> Reader is a PDA and so more powerful than the Lexer (a DFA or 
>> equivalent), but it is much simpler than a full JS parser -- and you 
>> need a Reader for macros.
>
> That's not possible.  See, for example, the case I showed during the 
> meeting:
>
> boom = yield/area/
> height;
>
> Is /area/ a regexp or two divisions and a variable?  You can't tell if 
> you're using a purported universal parser based on ES5.1 and are 
> unaware that yield is a contextual keyword which will be introduced 
> into the language in ES6.  And yes, you can then get arbitrarily out 
> of sync:
>
> boom = yield/a+"3/ string?"  ...

As I said to you at the meeting, there may be no problem if we simply 
stop adding contextual keywords and add macros instead.

We already gave up on adding /re/x and good riddance. Getting macros 
while freezing special form syntax strikes me as possibly a very good 
trade-off. What do you think?

/be