Re: JS syntax future-proofing, Macros, the Reader (was: Performance concern with let/const)
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? ...
Waldemar
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: JS syntax future-proofing, Macros, the Reader (was: Performance concern with let/const)
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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: JS syntax future-proofing, Macros, the Reader (was: Performance concern with let/const)
My point is: how do you make sure you don't redefine an existing syntax? Or, if that the syntax you're defining for your personnal use will not be reclaimed by a next version of ES? // Polyfill for syntaxFeature: /*@cc_on /*@if !support syntaxFeature */ code that emulate the syntaxFeature /* @endif */ */ There's probably an anwser to that question, it's just that I'm not aware of it already :-) -Message d'origine- From: Brendan Eich Sent: Tuesday, September 18, 2012 7:17 PM To: François REMY Cc: Luke Hoban ; Andreas Rossberg ; Paul Leathers ; es-discuss@mozilla.org Subject: Re: JS syntax future-proofing, Macros, the Reader (was: Performance concern with let/const) François REMY wrote: | But if we have macros, then many progressive | enhancement and anti-regressive polyfill approaches can be done, even | with new syntax (not just with APIs). Seems like another good way of fixing the issue :-) However, this seems to require some form of conditionnal compilation to work , right? [1] [1] http://www.javascriptkit.com/javatutors/conditionalcompile.shtml Macros have nothing to do with conditional compilation _per se_. When you read Macros in a JS context, don't think the C Pre-Processor, think Scheme! /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: JS syntax future-proofing, Macros, the Reader (was: Performance concern with let/const)
François REMY wrote: My point is: how do you make sure you don't redefine an existing syntax? Or, if that the syntax you're defining for your personnal use will not be reclaimed by a next version of ES? // Polyfill for syntaxFeature: /*@cc_on /*@if !support syntaxFeature */ code that emulate the syntaxFeature /* @endif */ */ There's probably an anwser to that question, it's just that I'm not aware of it already :-) Yes, polyfilling means has-syntax testing. I'm told the sweet.js project is considering how to do this, but I bet a donut that it'll not look like CPP or @-CPP or any such ugly blast from the past. More in a bit. /be -Message d'origine- From: Brendan Eich Sent: Tuesday, September 18, 2012 7:17 PM To: François REMY Cc: Luke Hoban ; Andreas Rossberg ; Paul Leathers ; es-discuss@mozilla.org Subject: Re: JS syntax future-proofing, Macros, the Reader (was: Performance concern with let/const) François REMY wrote: | But if we have macros, then many progressive | enhancement and anti-regressive polyfill approaches can be done, even | with new syntax (not just with APIs). Seems like another good way of fixing the issue :-) However, this seems to require some form of conditionnal compilation to work , right? [1] [1] http://www.javascriptkit.com/javatutors/conditionalcompile.shtml Macros have nothing to do with conditional compilation _per se_. When you read Macros in a JS context, don't think the C Pre-Processor, think Scheme! /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: JS syntax future-proofing, Macros, the Reader (was: Performance concern with let/const)
It's still early to say. But my feeling is that if we can get macros working, we can introduce new syntax via modules, not just unconditionally throwing them in everywhere. Then you don't have to do these kinds of global conditional things; rather, you just import the syntax from modules. The dynamic testing would then be done during app setup, when you construct your global environment before running the client code that uses it. The goal of macros is to make syntax more modular. Dave On Sep 18, 2012, at 2:23 PM, Brendan Eich bren...@mozilla.com wrote: François REMY wrote: My point is: how do you make sure you don't redefine an existing syntax? Or, if that the syntax you're defining for your personnal use will not be reclaimed by a next version of ES? // Polyfill for syntaxFeature: /*@cc_on /*@if !support syntaxFeature */ code that emulate the syntaxFeature /* @endif */ */ There's probably an anwser to that question, it's just that I'm not aware of it already :-) Yes, polyfilling means has-syntax testing. I'm told the sweet.js project is considering how to do this, but I bet a donut that it'll not look like CPP or @-CPP or any such ugly blast from the past. More in a bit. /be -Message d'origine- From: Brendan Eich Sent: Tuesday, September 18, 2012 7:17 PM To: François REMY Cc: Luke Hoban ; Andreas Rossberg ; Paul Leathers ; es-discuss@mozilla.org Subject: Re: JS syntax future-proofing, Macros, the Reader (was: Performance concern with let/const) François REMY wrote: | But if we have macros, then many progressive | enhancement and anti-regressive polyfill approaches can be done, even | with new syntax (not just with APIs). Seems like another good way of fixing the issue :-) However, this seems to require some form of conditionnal compilation to work , right? [1] [1] http://www.javascriptkit.com/javatutors/conditionalcompile.shtml Macros have nothing to do with conditional compilation _per se_. When you read Macros in a JS context, don't think the C Pre-Processor, think Scheme! /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
