The discussion of parser APIs had a side-thread on language
versioning which I'd like to raise separately, for those not
following the parser discussions. I include the relevant
context, then continue the thread below.
But there are also tough questions about what the parser
should do with
the AST API strawman ..
It hasn't really been championed so far. I was concentrating on
other proposals for ES.next.
So it was just timing, not behind-the-scenes disagreements. Ok.
- it does not support generic traversals, so it definitely needs a
pre-implemented traversal, sorting
On Jul 5, 2011, at 10:45 PM, Brendan Eich wrote:
On Jul 5, 2011, at 10:35 PM, Brendan Eich wrote:
On Jul 5, 2011, at 9:00 PM, David Herman wrote:
Mainstream production JS engines have moved away from parser generators.
Right, indeed most (all but JavaScriptCore, IINM) never used a
On Jul 5, 2011, at 10:45 PM, Brendan Eich wrote:
On Jul 5, 2011, at 10:35 PM, Brendan Eich wrote:
On Jul 5, 2011, at 9:00 PM, David Herman wrote:
Mainstream production JS engines have moved away from parser generators.
Right, indeed most (all but JavaScriptCore, IINM) never used a
On Jul 6, 2011, at 10:02 AM, Claus Reinke wrote:
the AST API strawman ..
It hasn't really been championed so far. I was concentrating on
other proposals for ES.next.
So it was just timing, not behind-the-scenes disagreements. Ok.
I don't think we have any consensus within TC39 WRT whether
This is all the stuff that will almost certainly require separate
implementations from the engine's core parser. And maybe
that's fine. In my case, I wanted to implement a reflection of
our existing parser, because it's guaranteed to track the
behavior of SpiderMonkey's parser.
On Jul 6, 2011, at 12:55 PM, Oliver Hunt wrote:
I have a vague recollection that the SM parser strips out some characters
prior to
parsing (brendan?)
Nothing is stripped other than space (including comments).
and generates bytecode into the ast (though based on dherman's
comments maybe
I don't think we have any consensus within TC39 WRT
whether such an API should be part of some future version
Ecma-262. Personally, this sounds like library functionality
that in the future might manifest as a module. I think we
need to draw a line at adding very many more such libraries
the AST API strawman - given the positive discussions on this list, I
thought the idea was implicitly accepted last year, modulo details,
so I was surprised not to see a refined strawman promoted.
It hasn't really been championed so far. I was concentrating on other proposals
for ES.next.
On Jul 5, 2011, at 9:00 PM, David Herman wrote:
- there are some minor oddities, from spelling differences to
the spec (Label(l)ed),
Heh, I shouldn't've capitulated to my (excellent and meticulous!) reviewer,
who was unfamiliar with the spec:
On Jul 5, 2011, at 10:35 PM, Brendan Eich wrote:
On Jul 5, 2011, at 9:00 PM, David Herman wrote:
Mainstream production JS engines have moved away from parser generators.
Right, indeed most (all but JavaScriptCore, IINM) never used a parser
generator in the first place. A great many
http://blog.mozilla.com/dherman/2011/06/28/the-js-parser-api-has-landed/
I’ve just read D. Herman’s post on Firefox’s parser API. Is there any chance
that this kind of API will make it into Harmony? It would be really useful for
a variety of generative/meta-programming tasks.
Axel
--
Dr.
On Tue, Jun 28, 2011 at 6:34 PM, Axel Rauschmayer a...@rauschma.de wrote:
http://blog.mozilla.com/dherman/2011/06/28/the-js-parser-api-has-landed/
I’ve just read D. Herman’s post on Firefox’s parser API. Is there any chance
that this kind of API will make it into Harmony? It would be really
On Tue, Jun 28, 2011 at 5:02 PM, Mike Shaver mike.sha...@gmail.com wrote:
On Tue, Jun 28, 2011 at 6:34 PM, Axel Rauschmayer a...@rauschma.de
wrote:
http://blog.mozilla.com/dherman/2011/06/28/the-js-parser-api-has-landed/
I’ve just read D. Herman’s post on Firefox’s parser API. Is there
Maybe we could start with an “official” separate JavaScript-only implementation?
On Jun 29, 2011, at 1:05 , Mark S. Miller wrote:
Hi Axel, I'm glad you're asking the right question. To clarify for everyone,
EcmaScript-Harmony (or just Harmony) names our agreed trajectory for the
language
Yeah, tough questions. I don't know. I tried to make the API flexible by
allowing custom builders, and in fact if you look at the test suite you'll see
I did a proof-of-concept showing how you could generate the format that Mark
mentioned:
16 matches
Mail list logo
