Hi Brendan
Picking up where Tom left off below... I've wondered how you and the
ECMAScript body prefer to have
particular concepts presented. Given that the lag time between new syntax and
conformance across vendors
could be months, years or never, it seems that there is always a need to
First, this traits proposal looks very nice -- thanks, Tom and Mark, for your
work on this.
I want to add another point about the benefit of new syntax by calling out a
piece of the code.google.com proposal under Performance, where it says: In
order for the partial evaluation scheme to work,
The proposals, including from Tom and Mark, don't steer away from const f() {} and other new syntax (destructuring).Harmony has new syntax, this is not an open issue.As we've discussed over the years, the language's users deserve new syntax, particularly for early error reporting. Implementors
The proposals, including from Tom and Mark, don't steer away from
const f() {} and other new syntax (destructuring).
Harmony has new syntax, this is not an open issue. As we've discussed
over the years, the language's users deserve new syntax, particularly
for early error reporting.
On Feb 19, 2010, at 9:28 AM, Brendan Eich wrote:
An example: IE4 had regexps close enough to match Netscape 4.x, but
IE4 lacked not try/catch/finally,
Sorry for the doubled post (and the stray not after lacked).
/be
___
es-discuss mailing list
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
On Feb 19, 2010, at 9:28 AM, Brendan Eich wrote:
Content authors will have to decide among the several solutions. The
JS community should and no doubt will make translation tools
available (even in-browser translators, where feasible).
To make a more useful followup to my own message, I
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
Could macros - or some kind of AOP-ish compile time processing - help:
@addtrait mytrait myobj;
@import acme.mymod; // expands to const acme = {mymod: {myfunc: ...;
Macros wouldn't really solve the I can't parse this problem. You could
package up syntax extensions as macros and provide them
On Fri, Feb 19, 2010 at 6:33 PM, David Herman dher...@mozilla.com wrote:
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
thanks Dave, Brendan.
the net-net then is to emphasize syntax but when possible outline a migration
path. This may have been obvious
to many but at least I've been very conservative about suggesting new syntax.
Worth far more than 2 pennies :)
kam
From:
Do the various server-side implementations count for example ejsscript which
incorporated many features of es4?
Or is the list specific to translation engines that take some ecmascript
derivative and produce harmony or es5?
Given what I've seen in translators to javascript from language 'X', the
On Feb 19, 2010, at 11:43 AM, Kam Kasravi wrote:
Do the various server-side implementations count for example
ejsscript which incorporated many features of es4?
Or is the list specific to translation engines that take some
ecmascript derivative and produce harmony or es5?
Given what I've
On Fri, Feb 19, 2010 at 8:58 AM, David Herman dher...@mozilla.com wrote:
First, this traits proposal looks very nice -- thanks, Tom and Mark, for
your work on this.
I want to add another point about the benefit of new syntax by calling out
a piece of the code.google.com proposal under
14 matches
Mail list logo
