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 engin
> Ah, sorry. Seems I got the wrong impression from the list archives - perhaps
> only the interested parties participated in
> those older threads. Thanks for clarifying.
I think you're looking for a thumbs-up/thumbs-down answer from TC39, when we
haven't really discussed it that much. We've exp
>>> - it is biased towards evaluation, which is a hindrance for other
>>> uses (such as faithful unparsing, for program transformations);
>>
>> It's just a reflection of the built-in SpiderMonkey parser, which was
>> designed for the sole purpose of evaluation. I didn't reimplement a
>> new
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
to
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 may
>> 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.
>
>
- it is slightly easier to manipulate than an Array-based AST, but
More than slightly, IMO.
Ok. Though destructuring closes some of the gap.
lack of pattern matching fall-through (alternative patterns for
destructuring) still hurts, and the selectors are lengthy, which
ham
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
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
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
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 ou
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
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:
>
>https://bugzilla.mozilla.or
On Wed, Jul 6, 2011 at 12:00 AM, David Herman wrote:
>> 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
> 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.
Hi Dave, and other interested parties,
it would be helpful to summarize the issues on a page linked from
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 promo
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:
http://hg.mozilla.org/tracemonkey/file/2ce7546583f
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
> langu
On Tue, Jun 28, 2011 at 5:02 PM, Mike Shaver wrote:
> On Tue, Jun 28, 2011 at 6:34 PM, Axel Rauschmayer
> 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 A
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 following ES5. We understand that the goals of this trajectory will
take several new editions to realize. "ES-next" is our working name
On Tue, Jun 28, 2011 at 6:34 PM, Axel Rauschmayer 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 useful
> for
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. Axel
22 matches
Mail list logo
