brendan at mozilla.com
Tue Jul 5 22:35:46 PDT 2011
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:
> I can probably change that.
Your API names do not follow the spec (which I'm not complaining about), so I don't see why they must use UK spelling (misspellings, in my humble opinion!) of "Labeled". :-P
>> btw, why alternate/consequent instead of then/else, and
> I was avoiding using keywords as property names, and consequent/alternate are standard terminology. I suppose .then/.else would be more convenient.
Is there any way an engine not supporting reserved identifiers as property names could use Reflect.parse-based (conditionally-based) code? I.e. is avoiding .else desirable? If not, then I'm +1 on .then and .else as shorter and plainer names.
>> (though IDEs will similarly need more info, for comment extraction,
>> syntax highlighting, and syntax-based operations).
> 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.
Agreed, this is a critical point. For any AST standard (which won't be in ES.next, Claus should note -- cutoff was May), implementors will not want to write two parsers and keep them in sync. We'll have to find common ground among implementations. This is uncertain and it will take at least time and a spirit of compromise among implementors.
> I'm still not convinced this is such a big win. Reflect.parse gives you *some* performance, but it still requires two traversals (one to generate the internal C++ JSParseNode tree and then a second to convert that to a JS object tree). But part of the benefit is knowing you have exactly the SpiderMonkey parser. Once implementors have to write a separate parser, the possibility of divergence increases, and the maintenance cost of building a second parser in a low-level language is high. At that point, they might just want to write it in JS. But anybody could do that.
+1 again -- divergence bugs in an implementation, plus the footprint hit, are two strikes against two parsers instead of one. OTOH implementing in JS is "just library code" and there won't be a need for a de-jure standard ahead of de-facto competition.
>> It should not be, provided one distinguishes between
>> standards-compliant and production use. If the ES grammar
>> is LR(1), it should really be specified in a parser tool format,
> Mainstream production JS engines have moved away from parser generators.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss