Short Comparing proposal

[Sendil Kumar N]

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,  wrote:

> Send es-discuss mailing list submissions to
> es-discuss@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-requ...@mozilla.org
>
> You can reach the person managing the list at
> es-discuss-ow...@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 
> To: "T.J. Crowder" 
> Cc: "es-discuss@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  com> wrote:
>
>> On Thu, Feb 2, 2017 at 12:38 PM, Michał Wadas 
>> 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
>>> 
>>> of the Object prototype object is null and the initial value of the
>>> [[Extensible]] internal slot
>>> 
>>> 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@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> -- Forwarded message --
> From: Jordan Harband 
> To: "T.J. Crowder" 
> Cc: "es-discuss@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.crow...@farsightsoftware.com> wrote:
>
>> On Wed, Feb 1, 2017 at 7:18 PM, Jeremy Darling 
>> 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@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> -- Forwarded message --
> From: Waldemar Horwat 
> To: Dmitry Soshnikov , Michael Dyck <
> jmd...@ibiblio.org>
> Cc: es-discuss 
> 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, 

Re: LR(1) grammar/parser and lookahead-restrictions

[Dmitry Soshnikov]

On Thu, Feb 2, 2017 at 3:56 PM, Dmitry Soshnikov  wrote:

> On Thu, Feb 2, 2017 at 3:23 PM, Waldemar Horwat 
> 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` extra productions?
>
>

Or you actually mean "lookahead-parametrized" productions (like in SLR(1)
which doesn't use it, vs. LALR(1), or CLR(1) which do use it)?

Dmitry
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: LR(1) grammar/parser and lookahead-restrictions

[Dmitry Soshnikov]

On Thu, Feb 2, 2017 at 3:23 PM, Waldemar Horwat  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` 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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: LR(1) grammar/parser and lookahead-restrictions

[Waldemar Horwat]

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

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Short Comparing proposal

[Jordan Harband]

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.crow...@farsightsoftware.com> wrote:

> On Wed, Feb 1, 2017 at 7:18 PM, Jeremy Darling 
> 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@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Is it spec-compliant to forbid setPrototypeOf(Object.prototype, foo)?

[Jordan Harband]

Also, `Object.freeze` causes `Object.setPrototypeOf` to fail.

On Thu, Feb 2, 2017 at 4:40 AM, T.J. Crowder <
tj.crow...@farsightsoftware.com> wrote:

> On Thu, Feb 2, 2017 at 12:38 PM, Michał Wadas 
> 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
>> 
>> of the Object prototype object is null and the initial value of the
>> [[Extensible]] internal slot
>> 
>> 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@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Is it spec-compliant to forbid setPrototypeOf(Object.prototype, foo)?

[T.J. Crowder]

On Thu, Feb 2, 2017 at 12:38 PM, Michał Wadas  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
> 
> of the Object prototype object is null and the initial value of the
> [[Extensible]] internal slot
> 
> 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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Is it spec-compliant to forbid setPrototypeOf(Object.prototype, foo)?

[Michał Wadas]

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


of the Object prototype object is null and the initial value of the
[[Extensible]] internal slot


is true.


On 02/02/17 13:31, T.J. Crowder wrote:
> On Thu, Feb 2, 2017 at 12:19 PM, Michał Wadas  > wrote:
>
> Right now this code:
>
> Object.setPrototypeOf(Object.prototype, Object.create(null))
>
> throws in both Chrome and Firefox. I couldn't find any mention of
> special [[SetPrototypeOf]] of %ObjectPrototype%, did I miss something?
>
> Yes. :-) You missed that `Object.prototype` is an immutable prototype
> exotic object:
>
> * 
> https://tc39.github.io/ecma262/#sec-properties-of-the-object-prototype-object
> * https://tc39.github.io/ecma262/#sec-immutable-prototype-exotic-objects
>
> ...which does indeed have a special [[SetPrototypeOf]] which
> (indirectly) returns false if you try to change the [[Prototype].
> `Object.setPrototypeOf` throws when [[SetPrototypeOf]] returns
> false: https://tc39.github.io/ecma262/#sec-object.setprototypeof
>
> -- T.J.

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Is it spec-compliant to forbid setPrototypeOf(Object.prototype, foo)?

[T.J. Crowder]

On Thu, Feb 2, 2017 at 12:19 PM, Michał Wadas  wrote:

> Right now this code:
>
> Object.setPrototypeOf(Object.prototype, Object.create(null))
>
> throws in both Chrome and Firefox. I couldn't find any mention of special
> [[SetPrototypeOf]] of %ObjectPrototype%, did I miss something?
>
Yes. :-) You missed that `Object.prototype` is an immutable prototype
exotic object:

*
https://tc39.github.io/ecma262/#sec-properties-of-the-object-prototype-object
* https://tc39.github.io/ecma262/#sec-immutable-prototype-exotic-objects

...which does indeed have a special [[SetPrototypeOf]] which (indirectly)
returns false if you try to change the [[Prototype].
`Object.setPrototypeOf` throws when [[SetPrototypeOf]] returns false:
https://tc39.github.io/ecma262/#sec-object.setprototypeof

-- T.J.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Is it spec-compliant to forbid setPrototypeOf(Object.prototype, foo)?

[Michał Wadas]

Right now this code:

Object.setPrototypeOf(Object.prototype, Object.create(null))

throws in both Chrome and Firefox. I couldn't find any mention of
special [[SetPrototypeOf]] of %ObjectPrototype%, did I miss something?

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Operator overloading, via Symbol.arithmetic?

[Igor Baklan]

previous discussion (FYI)
[operator-overloading-proposal](/topic/operator-overloading-proposal)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Short Comparing proposal

[T.J. Crowder]

On Wed, Feb 1, 2017 at 7:18 PM, Jeremy Darling 
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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Short Comparing proposal

[T.J. Crowder]

On Wed, Feb 1, 2017 at 7:18 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> I understand, but you can also ternary within a ternary so why would this
> have different capabilities ?
>

Because `if (x === (|| 2, (&& 3, y === 1)))` is trying to use only *half*
of the expression within another expression. But using a conditional within
a conditional is using an entire expression within another expression,
which is fine.

-- T.J.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss