Traits library

Brendan Eich brendan at
Fri Feb 19 10:31:49 PST 2010

On Feb 19, 2010, at 9:33 AM, Kevin Curtis wrote:

> Kam, interesting point. The same issues apply to modules as well as  
> traits:
> - module {} vs Module()
> - new syntax vs ES5-ish Meta Api
> - compile time vs runtime
> Could macros - or some kind of AOP-ish compile time processing - help:
> @addtrait mytrait myobj;
> @import acme.mymod; // expands to const acme = {mymod: {myfunc: ...;
> An ES-Harmony goal is to: "Provide syntactic conveniences ...defined  
> by desugaring into kernel semantics."
> How could this be achieved? Macro source expansion? What is truly  
> new 'kernel semantics' as opposed to syntax sugar? Interesting stuff.

There's no need to ape the C Pre-Processor (@ not #, etc.). Please  
don't let that influence you. FYI, there's already an @if/@else/etc.  
preprocessor anguage in IE JScript.

Harmony has new syntax, with semantics defined by desugaring where  
doing so yields an unambiguous, abstraction-leak-free, and simple- 
enough and clear-enough spec that implementors (the primary spec  
audience) are most likely to create interoperable implementations.

The Harmony syntax, whatever it is (and some is approved, e.g.  
destructuring, spread, rest -- see 
, can be translated to ES3+quirks, as needed.

The quirks may be more challenging than the relatively mundane  
(outside of generators) issues in targeting ES3.

The translation may have to work harder without @ to anchor its  
parsing or lexing (or regexp matching). The benefit is that users can  
program in the Harmony edition cross-browser. Let the translator  
authors bear the costs of parsing the full langage and "lowering" it  
to target old browsers.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list