Short Comparing proposal

Sendil Kumar N sendilkumarn.opensource at gmail.com
Fri Feb 3 06:32:50 UTC 2017 

This is a far more useful option and more sugary syntax. We can use
`<| ` as an identifier.

```

// <| ( operator, arguments )

if (object.property.secondProp ===  <|(||, 'a' , 'b')) {
    // do Something
}


if (object.property.secondProp ===  <|(&&, 'a' , 'b')) {
    // do Something
}

```

In case of testing nested


```

if (object.property.secondProp ===  <|((||, 'a' ,(&&, 'c' , 'b'))) {
    // do Something
}

```


Thanks

Sendil Kumar N



On Fri, Feb 3, 2017 at 7:56 AM, <es-discuss-request at mozilla.org> wrote:

> Send es-discuss mailing list submissions to
>         es-discuss at mozilla.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mail.mozilla.org/listinfo/es-discuss
> or, via email, send a message with subject or body 'help' to
>         es-discuss-request at mozilla.org
>
> You can reach the person managing the list at
>         es-discuss-owner at mozilla.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of es-discuss digest..."
>
> Today's Topics:
>
>    1. Re: Is it spec-compliant to forbid
>       setPrototypeOf(Object.prototype,  foo)? (Jordan Harband)
>    2. Re: Short Comparing proposal (Jordan Harband)
>    3. Re: LR(1) grammar/parser and lookahead-restrictions
>       (Waldemar Horwat)
>    4. Re: LR(1) grammar/parser and lookahead-restrictions
>       (Dmitry Soshnikov)
>
>
> ---------- Forwarded message ----------
> From: Jordan Harband <ljharb at gmail.com>
> To: "T.J. Crowder" <tj.crowder at farsightsoftware.com>
> Cc: "es-discuss at mozilla.org" <es-discuss at mozilla.org>
> Date: Thu, 2 Feb 2017 11:20:20 -0800
> Subject: Re: Is it spec-compliant to forbid
> setPrototypeOf(Object.prototype, foo)?
> Also, `Object.freeze` causes `Object.setPrototypeOf` to fail.
>
> On Thu, Feb 2, 2017 at 4:40 AM, T.J. Crowder <tj.crowder at farsightsoftware.
> com> wrote:
>
>> On Thu, Feb 2, 2017 at 12:38 PM, Michał Wadas <michalwadas at gmail.com>
>> wrote:
>>
>>> Thanks, I erroneously looked at ES2015 spec that calls Object.prototype
>>> ordinary object.
>>>
>>> The Object prototype object is the intrinsic object %ObjectPrototype%.
>>> The Object prototype object is an ordinary object.
>>> The value of the [[Prototype]] internal slot
>>> <http://www.ecma-international.org/ecma-262/6.0/#sec-object-internal-methods-and-internal-slots>
>>> of the Object prototype object is null and the initial value of the
>>> [[Extensible]] internal slot
>>> <http://www.ecma-international.org/ecma-262/6.0/#sec-object-internal-methods-and-internal-slots>
>>> is true.
>>>
>>> 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...
>>
>> -- T.J.
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> ---------- Forwarded message ----------
> From: Jordan Harband <ljharb at gmail.com>
> To: "T.J. Crowder" <tj.crowder at farsightsoftware.com>
> Cc: "es-discuss at mozilla.org" <es-discuss at mozilla.org>
> Date: Thu, 2 Feb 2017 11:24:41 -0800
> Subject: Re: Short Comparing proposal
> 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.
>
> On Thu, Feb 2, 2017 at 12:46 AM, T.J. Crowder <
> tj.crowder at farsightsoftware.com> wrote:
>
>> On Wed, Feb 1, 2017 at 7:18 PM, Jeremy Darling <jeremy.darling at gmail.com>
>> wrote:
>>
>>> 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.
>>>
>>
>> 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.
>>
>> 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...
>>
>> -- T.J.
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> ---------- Forwarded message ----------
> From: Waldemar Horwat <waldemar at google.com>
> To: Dmitry Soshnikov <dmitry.soshnikov at gmail.com>, Michael Dyck <
> jmdyck at ibiblio.org>
> Cc: es-discuss <es-discuss at mozilla.org>
> Date: Thu, 2 Feb 2017 15:23:18 -0800
> Subject: Re: LR(1) grammar/parser and lookahead-restrictions
> On 02/01/2017 10:25, Dmitry Soshnikov wrote:
>
>> 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).
>>
>
> 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.
>
> When designing the grammar, the preferences are:
>
> - Use standard LR(1) productions
> - Use parametrized productions
> - Use lookahead restrictions if parametrized productions would introduce
> too many parameters into rules
> - 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.
>
> 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.
>
> The same problem is even worse for cover grammars.
>
>     Waldemar
>
>
>
>
> ---------- Forwarded message ----------
> From: Dmitry Soshnikov <dmitry.soshnikov at gmail.com>
> To: Waldemar Horwat <waldemar at google.com>
> Cc: es-discuss <es-discuss at mozilla.org>
> Date: Thu, 2 Feb 2017 15:56:23 -0800
> Subject: Re: LR(1) grammar/parser and lookahead-restrictions
> On Thu, Feb 2, 2017 at 3:23 PM, Waldemar Horwat <waldemar at google.com>
> wrote:
>
>> On 02/01/2017 10:25, Dmitry Soshnikov wrote:
>>
>>> 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).
>>>
>>
>> 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.
>>
>>
> 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.
>
> 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.
>
>
>> When designing the grammar, the preferences are:
>>
>> - Use standard LR(1) productions
>> - Use parametrized productions
>> - Use lookahead restrictions if parametrized productions would introduce
>> too many parameters into rules
>> - 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.
>>
>>
> Just to double-check, by "parametrized productions" you mean the
> `No<lookahead>` extra productions?
>
>
>> 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.
>>
>> The same problem is even worse for cover grammars.
>>
>>
> 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.
>
> Dmitry
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170203/64499e25/attachment-0001.html>

More information about the es-discuss mailing list