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

Brendan Eich brendan at mozilla.com
Tue Sep 18 11:23:09 PDT 2012


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 at 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
>


More information about the es-discuss mailing list