On Fri, Feb 19, 2010 at 8:58 AM, David Herman 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 "Performance," where
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 seen
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
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: Dav
On Fri, Feb 19, 2010 at 6:33 PM, David Herman 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 sugar? Inter
> 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 th
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 myt
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 sho
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 ac
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
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. Impleme
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 als
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,
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
pr
14 matches
Mail list logo
