<div dir="ltr"><pre style="white-space:pre-wrap;color:rgb(0,0,0)">This is a far more useful option and more sugary syntax. We can use `<| ` as an identifier. </pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)">```</pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)">// <| ( operator, arguments )</pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)">if (object.property.secondProp ===  <|(||, 'a' , 'b')) {
    // do Something
}</pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)"><br></pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)"><pre style="white-space:pre-wrap">if (object.property.secondProp ===  <|(&&, 'a' , 'b')) {
    // do Something
}</pre></pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)">```</pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)">In case of testing nested</pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)"><br></pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)"><pre style="white-space:pre-wrap">```</pre><pre style="white-space:pre-wrap">if (object.property.secondProp ===  <|((||, 'a' ,(&&, 'c' , 'b'))) {
    // do Something
}</pre><pre style="white-space:pre-wrap">```</pre><pre style="white-space:pre-wrap"><br></pre><pre style="white-space:pre-wrap">Thanks</pre><pre style="white-space:pre-wrap">Sendil Kumar N</pre></pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)"><br></pre><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 3, 2017 at 7:56 AM,  <span dir="ltr"><<a href="mailto:es-discuss-request@mozilla.org" target="_blank">es-discuss-request@mozilla.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send es-discuss mailing list submissions to<br>
        <a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/es-discuss</a><br>
or, via email, send a message with subject or body 'help' to<br>
        <a href="mailto:es-discuss-request@mozilla.org">es-discuss-request@mozilla.org</a><br>
<br>
You can reach the person managing the list at<br>
        <a href="mailto:es-discuss-owner@mozilla.org">es-discuss-owner@mozilla.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of es-discuss digest..."<br>
<br>Today's Topics:<br>
<br>
   1. Re: Is it spec-compliant to forbid<br>
      setPrototypeOf(Object.<wbr>prototype,  foo)? (Jordan Harband)<br>
   2. Re: Short Comparing proposal (Jordan Harband)<br>
   3. Re: LR(1) grammar/parser and lookahead-restrictions<br>
      (Waldemar Horwat)<br>
   4. Re: LR(1) grammar/parser and lookahead-restrictions<br>
      (Dmitry Soshnikov)<br>
<br><br>---------- Forwarded message ----------<br>From: Jordan Harband <<a href="mailto:ljharb@gmail.com">ljharb@gmail.com</a>><br>To: "T.J. Crowder" <<a href="mailto:tj.crowder@farsightsoftware.com">tj.crowder@farsightsoftware.com</a>><br>Cc: "<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a>" <<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a>><br>Date: Thu, 2 Feb 2017 11:20:20 -0800<br>Subject: Re: Is it spec-compliant to forbid setPrototypeOf(Object.prototype, foo)?<br><div dir="ltr">Also, `Object.freeze` causes `Object.setPrototypeOf` to fail.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 2, 2017 at 4:40 AM, T.J. Crowder <span dir="ltr"><<a href="mailto:tj.crowder@farsightsoftware.com" target="_blank">tj.crowder@farsightsoftware.<wbr>com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Thu, Feb 2, 2017 at 12:38 PM, Michał Wadas <span dir="ltr"><<a href="mailto:michalwadas@gmail.com" target="_blank">michalwadas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF">
    <p><font face="Helvetica, Arial, sans-serif">Thanks, I erroneously
        looked at ES2015 spec that calls Object.prototype ordinary
        object.<br>
      </font></p>
    <blockquote>The Object prototype object is the intrinsic object
      %ObjectPrototype%. The Object prototype object is an ordinary
      object. <br>
      The value of the [[Prototype]] <a href="http://www.ecma-international.org/ecma-262/6.0/#sec-object-internal-methods-and-internal-slots" target="_blank">internal
        slot</a> of the Object prototype object is <span class="m_-1153884539513117527m_-6567679874945261040gmail-m_-888501796661816078value">null</span>
      and the initial value of the [[Extensible]] <a href="http://www.ecma-international.org/ecma-262/6.0/#sec-object-internal-methods-and-internal-slots" target="_blank">internal
        slot</a> is <span class="m_-1153884539513117527m_-6567679874945261040gmail-m_-888501796661816078value">true</span>.</blockquote></div></blockquote></span><div class="gmail_quote">Ah! I looked in the ES2016 spec to make sure it wasn't a recent change, didn't think to go back to the one before...<span class="m_-1153884539513117527HOEnZb"><font color="#888888"><br></font></span></div><span class="m_-1153884539513117527HOEnZb"><font color="#888888"><div><br></div><div>-- T.J.</div><div> </div></font></span></div></div></div>
<br>______________________________<wbr>_________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listi<wbr>nfo/es-discuss</a><br>
<br></blockquote></div><br></div>
<br><br>---------- Forwarded message ----------<br>From: Jordan Harband <<a href="mailto:ljharb@gmail.com">ljharb@gmail.com</a>><br>To: "T.J. Crowder" <<a href="mailto:tj.crowder@farsightsoftware.com">tj.crowder@farsightsoftware.com</a>><br>Cc: "<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a>" <<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a>><br>Date: Thu, 2 Feb 2017 11:24:41 -0800<br>Subject: Re: Short Comparing proposal<br><div dir="ltr">It seems like a far more useful proposal (although much larger in scope) would be some concept of interface comparison, and then you could see if `object` matches "an interface that has an `a` and `b` property", but also if `object` is "arraylike", or "iterable", or a "thenable", etc.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 2, 2017 at 12:46 AM, T.J. Crowder <span dir="ltr"><<a href="mailto:tj.crowder@farsightsoftware.com" target="_blank">tj.crowder@farsightsoftware.<wbr>com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Wed, Feb 1, 2017 at 7:18 PM, Jeremy Darling <span dir="ltr"><<a href="mailto:jeremy.darling@gmail.com" target="_blank">jeremy.darling@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">This is an interesting concept, but reuse of ()'s and : will make it difficult to pin down, scale to other operators and communicate.  Really the "inclusion" operator needs to be something that stands out, doesn't break existing spec, and won't kill new specs.</div></blockquote><div><br></div></span><div>Completely agreed. The trick is finding that something. We're definitely out of single-character options, so something along the lines you describe would be better. `$` is probably not going to be an option as the lead character, as it's an identifier character.<br></div><div><br></div><div>I don't know how the process works, though. Is it too early to be thinking about syntax? The first question probably has to be whether it's worth exploring new syntax in this area at all, *then* exploring what that syntax might be...<span class="m_-2055462758550333726HOEnZb"><font color="#888888"><br></font></span></div><span class="m_-2055462758550333726HOEnZb"><font color="#888888"><div><br></div><div>-- T.J.</div></font></span></div></div></div>
<br>______________________________<wbr>_________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listi<wbr>nfo/es-discuss</a><br>
<br></blockquote></div><br></div>
<br><br>---------- Forwarded message ----------<br>From: Waldemar Horwat <<a href="mailto:waldemar@google.com">waldemar@google.com</a>><br>To: Dmitry Soshnikov <<a href="mailto:dmitry.soshnikov@gmail.com">dmitry.soshnikov@gmail.com</a>>, Michael Dyck <<a href="mailto:jmdyck@ibiblio.org">jmdyck@ibiblio.org</a>><br>Cc: es-discuss <<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a>><br>Date: Thu, 2 Feb 2017 15:23:18 -0800<br>Subject: Re: LR(1) grammar/parser and lookahead-restrictions<br>On 02/01/2017 10:25, Dmitry Soshnikov wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As mentioned, Cover grammar is usually the process of the grammar design itself (as in ES6 spec itself). I'm not aware of automatic transformations for this (if you find any please let me know).<br>
</blockquote>
<br>
Cover grammars are an ugly hack that we had to add when there was no other practical choice.  Avoid them as much as possible.  They are only used in situations where lookahead restrictions and parametrized grammar rules do not work in any practical way.<br>
<br>
When designing the grammar, the preferences are:<br>
<br>
- Use standard LR(1) productions<br>
- Use parametrized productions<br>
- Use lookahead restrictions if parametrized productions would introduce too many parameters into rules<br>
- Use a cover grammar if the grammar can't be reasonably expressed in any other way.  They're a last resort with lots of problems.<br>
<br>
Lookahead restrictions fit very well into an LR(1) engine as long as they're limited to only one token, and that's what I've implemented in the validator.  You need to be very careful with them if looking more than one token ahead because lexing of the tokens can vary based on context.  For example, if the next few characters in front of the cursor are )/abc/i+, then what is the second token?  What is the third token?  It's actually context-dependent.<br>
<br>
The same problem is even worse for cover grammars.<br>
<br>
    Waldemar<br>
<br>
<br>
<br><br>---------- Forwarded message ----------<br>From: Dmitry Soshnikov <<a href="mailto:dmitry.soshnikov@gmail.com">dmitry.soshnikov@gmail.com</a>><br>To: Waldemar Horwat <<a href="mailto:waldemar@google.com">waldemar@google.com</a>><br>Cc: es-discuss <<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a>><br>Date: Thu, 2 Feb 2017 15:56:23 -0800<br>Subject: Re: LR(1) grammar/parser and lookahead-restrictions<br><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Feb 2, 2017 at 3:23 PM, Waldemar Horwat <span dir="ltr"><<a href="mailto:waldemar@google.com" target="_blank">waldemar@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 02/01/2017 10:25, Dmitry Soshnikov wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As mentioned, Cover grammar is usually the process of the grammar design itself (as in ES6 spec itself). I'm not aware of automatic transformations for this (if you find any please let me know).<br>
</blockquote>
<br></span>
Cover grammars are an ugly hack that we had to add when there was no other practical choice.  Avoid them as much as possible.  They are only used in situations where lookahead restrictions and parametrized grammar rules do not work in any practical way.<br>
<br></blockquote><div><br></div><div>Yeah, absolutely agreed. The reason why I used cover grammar in that example to parse `{` as a `Block` vs. `ObjectLiteral`, and handle `ExpressionStatement` is to make the resulting grammar short, and don't introduce a bunch of `NoCurly`, etc extra productions for this. That's also said, this ugly hack also forces you to do post-processing overhead -- either validation of the nodes, or even re-interpretation (rewriting) to other nodes -- in my case I have to actually check that all nodes between `{` and `}` are properties, or vice-versa, statements, based on the expression/statement position.</div><div><br></div><div>Practically, a cover grammar still can be slower because of such post-processing overhead (imaging you have a giant file with just object -- all those now are needed to be validated to contain property nodes). OTOH, a trade off with lookahead restrictions is introducing ~1.5x more parsing states.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
When designing the grammar, the preferences are:<br>
<br>
- Use standard LR(1) productions<br>
- Use parametrized productions<br>
- Use lookahead restrictions if parametrized productions would introduce too many parameters into rules<br>
- Use a cover grammar if the grammar can't be reasonably expressed in any other way.  They're a last resort with lots of problems.<br>
<br></blockquote><div><br></div><div>Just to double-check, by "parametrized productions" you mean the `No<lookahead>` extra productions?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Lookahead restrictions fit very well into an LR(1) engine as long as they're limited to only one token, and that's what I've implemented in the validator.  You need to be very careful with them if looking more than one token ahead because lexing of the tokens can vary based on context.  For example, if the next few characters in front of the cursor are )/abc/i+, then what is the second token?  What is the third token?  It's actually context-dependent.<br>
<br>
The same problem is even worse for cover grammars.<span class="m_-860276955287157808HOEnZb"><font color="#888888"><br><br></font></span></blockquote><div><br></div><div>Yeah, that's also true. Thanks again for the confirmation, that such a validator even exists, it's good -- at least we know it's parsable in principle. Those, that's said, on real practice now implementing a manual recursive descent for ECMAScript is more approachable now.</div><div><br></div><div>Dmitry </div></div></div></div>
<br>______________________________<wbr>_________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/es-discuss</a><br>
<br></blockquote></div><br></div></div>