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
