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 http://wiki.ecmascript.org/doku.php?id=harmony:proposals)
, 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.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
