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.org/show_bug.cgi?id=533874#c28
>
> 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.
Right, indeed most (all but JavaScriptCore, IINM) never used a parser generator
in the first place. A great many industrial language implementations do not use
generated parsers.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
