Brendan Eich (2013-10-28T15:22:29.000Z)
Brendan Eich wrote:
>> The API Function.defineOperator(symbol, type1, type2) would be 
>> perfect to support this. However I assume this is not the intention?  
>> Is there any openness to supporting user defined infix operators or 
>> at least an extended set similar to Python's PEP 225 proposal 
>> (http://www.python.org/dev/peps/pep-0225/)?
>
> I'm not proposing syntactically novel operator extension. That is hard 
> in a C-like language, but doable with enough work. It would be a 
> separate proposal on top. 

Just to set expectations, this won't be done quickly. As I understand 
it, http://sweetjs.org/ (macros for JS, Tim Disney's baby) needs to come 
along farther, and tackle "enforestation", before new infix operators 
support is anywhere near a strawman for an ECMA-262 future edition.

/be
domenic at domenicdenicola.com (2013-11-03T22:01:19.474Z)
Brendan Eich wrote:
> I'm not proposing syntactically novel operator extension. That is hard 
> in a C-like language, but doable with enough work. It would be a 
> separate proposal on top. 

Just to set expectations, this won't be done quickly. As I understand 
it, http://sweetjs.org/ (macros for JS, Tim Disney's baby) needs to come 
along farther, and tackle "enforestation", before new infix operators 
support is anywhere near a strawman for an ECMA-262 future edition.