Re: May 24-26 rough meeting notes

On May 29, 2011, at 2:58 PM, Thaddee Tyl wrote: > ... I believe that, given the fact that browsers will implement > ES.next incrementally, we should find a way to allow graceful > fallback, rather than version-driven conditionals. This is trivial for new global object properties, but such additio

Re: May 24-26 rough meeting notes

On Sun, May 29, 2011 at 10:00 PM, Brendan Eich wrote: > On May 29, 2011, at 12:55 PM, Thaddee Tyl wrote: > >> Don't be upset! > > Not at all, I'm simply skeptical (and saucy in saying so) about > jurisdictional fights this early in thinking creatively about cross-cutting > solutions. Seems kind

Re: ES parsing tools (Re: Short Functions)

Does Waldemar still maintain the tool? the source dates seemed fairly old... On May 29, 2011, at 12:21 PM, Brendan Eich wrote: > On May 29, 2011, at 2:11 AM, Claus Reinke wrote: > >> tl;dr: >> - JS-based PEG + ANTLR as a route for ES grammar experiments > > Mark and Tom already use Ometa at

Re: ES parsing tools (Re: Short Functions)

I've been experimenting with pegjs - which generates a parser based on the ecma-262 5th edition grammar. I've been building a backend that walks the ast to regenerate the code (less white related formatting). The nice thing about pegjs is most of the ast nodes agree with the parser api (https://

Re: May 24-26 rough meeting notes

On May 29, 2011, at 12:55 PM, Thaddee Tyl wrote: > Don't be upset! Not at all, I'm simply skeptical (and saucy in saying so) about jurisdictional fights this early in thinking creatively about cross-cutting solutions. Seems kind of silly to call process police, doesn't it? > I just believe th

Re: Array comprehensions shorter syntax (?)

On May 29, 2011, at 12:52 PM, Dmitry A. Soshnikov wrote: > P.S.: though, btw, IIRC, you said the same when an year ago I proposed arrow > functions or Ruby's blocks and they were refused because of grammar reasons; > today we want them to standardize ;) I mean, perhaps what seems not so needed

Re: ES parsing tools (Re: Short Functions)

On May 29, 2011, at 12:21 PM, Brendan Eich wrote: > Mark and Tom already use Ometa at a code.google.com project, as noted. What > more do you want? > > This does *not* address the issue of a usable spec grammar that can be > validated (my point (a)). In spite of over a thousand words and many

Re: May 24-26 rough meeting notes

Don't be upset! I just believe that new HTML syntax would be better off in the HTML living standard. More people read it, more people contribute to correcting its bugs. Getting involved in it can only be beneficial. On Sun, May 29, 2011 at 9:25 PM, Brendan Eich wrote: > On May 29, 2011, at 6:45

Re: Array comprehensions shorter syntax (?)

On 29.05.2011 23:29, Brendan Eich wrote: On May 29, 2011, at 7:17 AM, Jose Antonio Perez wrote: 2011/5/29 Dmitry A. Soshnikov > That's it, exactly. We always looking for a shorter sugar. Though, the main thing that the sugar shouldn't be cryptic at th

Re: Array comprehensions shorter syntax (?)

On May 29, 2011, at 7:17 AM, Jose Antonio Perez wrote: > 2011/5/29 Dmitry A. Soshnikov > > That's it, exactly. We always looking for a shorter sugar. Though, the main > thing that the sugar shouldn't be cryptic at the same time. Probably Erlang's > list comprehensions are cryptic for someone,

Re: May 24-26 rough meeting notes

On May 29, 2011, at 6:45 AM, Thaddee Tyl wrote: Consensus on moving some form of versioning into Harmony. The strawman is a bit light at this time, so no specifics yet. >>> >>> A lot of the above looks like HTML. Isn't versioning that depends on >>> HTML out of scope for the ECMA

Re: ES parsing tools (Re: Short Functions)

On May 29, 2011, at 2:11 AM, Claus Reinke wrote: > tl;dr: > - JS-based PEG + ANTLR as a route for ES grammar experiments Mark and Tom already use Ometa at a code.google.com project, as noted. What more do you want? This does *not* address the issue of a usable spec grammar that can be valida

Re: Array comprehensions shorter syntax (?)

Errata: + must be * ListComprehension : '[' Expression '|' IterableOrFilter (,IterableOrFilter)* ']' IterableOrFilter: Id '<-' ArrayOrGenerator | BooleanFilter Jose. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/

Re: Array comprehensions shorter syntax (?)

2011/5/29 Dmitry A. Soshnikov That's it, exactly. We always looking for a shorter sugar. Though, the main > thing that the sugar shouldn't be cryptic at the same time. Probably > Erlang's list comprehensions are cryptic for someone, but again, taking into > account arrow-functions, seems arrow-co

Re: Array comprehensions shorter syntax (?)

On 29.05.2011 17:45, François REMY wrote: An alternative syntax, which I tend to prefer, is a LINQ-like syntax. As I noted from the beginning I wouldn't like to turn the topic into bikesheding with all possible syntax constructions for comprehensions (once again, there many interesting in man

Re: May 24-26 rough meeting notes

> Date: Sat, 28 May 2011 12:57:04 -0700 > From: Brendan Eich > http://www.mail-archive.com/es-discuss@mozilla.org/msg05005.html had the > example I was trying to reconstruct from memory at last week's meeting: > > >  // new.js inline-exanded here > >   >   > > >>> Consensus on moving some form

Re: Array comprehensions shorter syntax (?)

An alternative syntax, which I tend to prefer, is a LINQ-like syntax. Please note that LINQ don’t produce an array, but an enumerable. It means that if the result is never used, the query is never executed (and if only the first result is used, the query only executed itself to that point, and n

Re: Array comprehensions shorter syntax (?)

On 29.05.2011 16:18, Jose Antonio Perez wrote: 2011/5/29 Dmitry A. Soshnikov > Hi, Don't get this proposal as a bikesheding, just an idea in case if arrow functions will win the block-functions. What about to make a sugar for Array comprehensi

Re: Array comprehensions shorter syntax (?)

2011/5/29 Dmitry A. Soshnikov > Hi, > > Don't get this proposal as a bikesheding, just an idea in case if arrow > functions will win the block-functions. > > What about to make a sugar for Array comprehensions based also on arrow > syntax? The same as in Erlang: > > let data = [1, 2, 3, 4, 5]; >

Array comprehensions shorter syntax (?)

Hi, Don't get this proposal as a bikesheding, just an idea in case if arrow functions will win the block-functions. What about to make a sugar for Array comprehensions based also on arrow syntax? The same as in Erlang: let data = [1, 2, 3, 4, 5]; let squares = [x * x | x <- data, x > 3]; /

Re: ES parsing tools (Re: Short Functions)

tl;dr: - JS-based PEG + ANTLR as a route for ES grammar experiments - would like to know about route viability and alternative routes If OMeta's should really be slower than similar parsers, and the grammar-optimizing side is covered by the authors, perhaps there is room for old-fashioned