Chained comparisons from Python and CoffeeScript

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Chained comparisons from Python and CoffeeScript

Andy Earnshaw-2
I apologise if I'm making more suggestions that have been discussed in the past, I'm genuinely searching before I click the compose button and not finding anything!

I'd like to see this implemented, at least for greater/less than (-or equal to).

    a < b < c
    a <= b <= c    

Desugars to

    a < b && b < c
    a <= b && b <= c

For a real-world example

    var pos = element.getBoundingClientRect(),
         inView = 0 <= pos.left && pos.left <= window.innerWidth && 0 <= pos.top && pos.top <= window.innerHeight;

Could be rewritten as

    var pos = element.getBoundingClientRect(),
         inView = 0 <= pos.left <= window.innerWidth && 0 <= pos.top <= window.innerHeight;

There's a lot to be said for readability, and each operand needs only be evaluated once, so it could help avoid the need for creating variables to store the result of a function or a getter (or prevent the need for either to be invoked more than once).  

It's also supported (as the title suggests) by Python [1], Perl 6 [2] and CoffeeScript [3].  Those languages support chaining the equality operators too.

It's potentially a breaking change, because

0 < 1 < 1

evaluates to false in current implementations because

(0 < 1) < 1

However, I think we'd be hard pressed to find code like this with greater/less than or equality operators.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Chained comparisons from Python and CoffeeScript

Tab Atkins Jr.
On Thu, Jul 18, 2013 at 4:34 PM, Andy Earnshaw <[hidden email]> wrote:
> It's potentially a breaking change, because
>
> 0 < 1 < 1
>
> evaluates to false in current implementations because
>
> (0 < 1) < 1

Luckily, this is false in the chained operations too, since "(0 < 1)
&& (1 < 1)" evaluates to false.

One problem is that in current Javascript, the equality and the
comparison operators are at different precedence levels.  Python puts
them at the same level, so that chaining can be purely left-to-right.
There's a decent chance that code does indeed depend on this, due to
testing equality of a comparison with a bool (which is stupid, but
people do it).

~TJ
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Chained comparisons from Python and CoffeeScript

Rick Waldron



On Fri, Jul 19, 2013 at 1:35 PM, Tab Atkins Jr. <[hidden email]> wrote:
On Thu, Jul 18, 2013 at 4:34 PM, Andy Earnshaw <[hidden email]> wrote:
> It's potentially a breaking change, because
>
> 0 < 1 < 1
>
> evaluates to false in current implementations because
>
> (0 < 1) < 1

Luckily, this is false in the chained operations too, since "(0 < 1)
&& (1 < 1)" evaluates to false.

One problem is that in current Javascript, the equality and the
comparison operators are at different precedence levels.  Python puts
them at the same level, so that chaining can be purely left-to-right.
There's a decent chance that code does indeed depend on this, due to
testing equality of a comparison with a bool (which is stupid, but
people do it).

While this is all true, the simple answer is:

var a = 1, b = 2, c = 3;
a < b < c; // true

is already valid JavaScript and can't be co-opted to express new runtime evaluation semantics.


Rick


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Chained comparisons from Python and CoffeeScript

Tab Atkins Jr.
On Fri, Jul 19, 2013 at 1:21 PM, Rick Waldron <[hidden email]> wrote:

> On Fri, Jul 19, 2013 at 1:35 PM, Tab Atkins Jr. <[hidden email]>
> wrote:
>>
>> On Thu, Jul 18, 2013 at 4:34 PM, Andy Earnshaw <[hidden email]>
>> wrote:
>> > It's potentially a breaking change, because
>> >
>> > 0 < 1 < 1
>> >
>> > evaluates to false in current implementations because
>> >
>> > (0 < 1) < 1
>>
>> Luckily, this is false in the chained operations too, since "(0 < 1)
>> && (1 < 1)" evaluates to false.
>>
>> One problem is that in current Javascript, the equality and the
>> comparison operators are at different precedence levels.  Python puts
>> them at the same level, so that chaining can be purely left-to-right.
>> There's a decent chance that code does indeed depend on this, due to
>> testing equality of a comparison with a bool (which is stupid, but
>> people do it).
>
> While this is all true, the simple answer is:
>
> var a = 1, b = 2, c = 3;
> a < b < c; // true
>
> is already valid JavaScript and can't be co-opted to express new runtime
> evaluation semantics.

Well, that's a bad example, because it's true with chained operators
too.  Let c = 1.5, though, and you get different behavior.

This type of code is broken in the first place, though.  Are we
assuming that it's prevalent enough to cause problems?

~TJ
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Chained comparisons from Python and CoffeeScript

Rick Waldron



On Fri, Jul 19, 2013 at 3:21 PM, Tab Atkins Jr. <[hidden email]> wrote:
On Fri, Jul 19, 2013 at 1:21 PM, Rick Waldron <[hidden email]> wrote:
> On Fri, Jul 19, 2013 at 1:35 PM, Tab Atkins Jr. <[hidden email]>
> wrote:
>>
>> On Thu, Jul 18, 2013 at 4:34 PM, Andy Earnshaw <[hidden email]>
>> wrote:
>> > It's potentially a breaking change, because
>> >
>> > 0 < 1 < 1
>> >
>> > evaluates to false in current implementations because
>> >
>> > (0 < 1) < 1
>>
>> Luckily, this is false in the chained operations too, since "(0 < 1)
>> && (1 < 1)" evaluates to false.
>>
>> One problem is that in current Javascript, the equality and the
>> comparison operators are at different precedence levels.  Python puts
>> them at the same level, so that chaining can be purely left-to-right.
>> There's a decent chance that code does indeed depend on this, due to
>> testing equality of a comparison with a bool (which is stupid, but
>> people do it).
>
> While this is all true, the simple answer is:
>
> var a = 1, b = 2, c = 3;
> a < b < c; // true
>
> is already valid JavaScript and can't be co-opted to express new runtime
> evaluation semantics.

Well, that's a bad example, because it's true with chained operators
too.  Let c = 1.5, though, and you get different behavior.

This type of code is broken in the first place, though.  Are we
assuming that it's prevalent enough to cause problems?

It doesn't matter if you think my example is a "bad example", it's a valid expression per the language's existing grammar.

Rick
 

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Chained comparisons from Python and CoffeeScript

Tab Atkins Jr.
On Fri, Jul 19, 2013 at 2:22 PM, Rick Waldron <[hidden email]> wrote:

> On Fri, Jul 19, 2013 at 3:21 PM, Tab Atkins Jr. <[hidden email]>
> wrote:
>> On Fri, Jul 19, 2013 at 1:21 PM, Rick Waldron <[hidden email]>
>> wrote:
>> > While this is all true, the simple answer is:
>> >
>> > var a = 1, b = 2, c = 3;
>> > a < b < c; // true
>> >
>> > is already valid JavaScript and can't be co-opted to express new runtime
>> > evaluation semantics.
>>
>> Well, that's a bad example, because it's true with chained operators
>> too.  Let c = 1.5, though, and you get different behavior.
>
> It doesn't matter if you think my example is a "bad example", it's a valid
> expression per the language's existing grammar.

It certainly does, because we don't expose the parsing directly.  If
we change the interpretation of a piece of code, but it outputs the
same or compatible values, we're fine.  It's only when the observable
results change incompatibly that we have to worry.  In your example,
you get a "true" regardless of the interpretation, which means you're
not demonstrating a problem with changing the interpretation.

~TJ
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Chained comparisons from Python and CoffeeScript

Andy Earnshaw-2
In reply to this post by Tab Atkins Jr.


On 19 Jul 2013 20:21, "Tab Atkins Jr." <[hidden email]> wrote:
>
> Well, that's a bad example, because it's true with chained operators
> too.  Let c = 1.5, though, and you get different behavior.
>
> This type of code is broken in the first place, though.  Are we
> assuming that it's prevalent enough to cause problems?
>

Well, I was hoping it wouldn't. I can't imagine anyone writing this kind of code unless they expect it to work in the same way as Python (and by chance it did when they tested).


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Chained comparisons from Python and CoffeeScript

Rick Waldron
In reply to this post by Tab Atkins Jr.



On Fri, Jul 19, 2013 at 5:43 PM, Tab Atkins Jr. <[hidden email]> wrote:
On Fri, Jul 19, 2013 at 2:22 PM, Rick Waldron <[hidden email]> wrote:
> On Fri, Jul 19, 2013 at 3:21 PM, Tab Atkins Jr. <[hidden email]>
> wrote:
>> On Fri, Jul 19, 2013 at 1:21 PM, Rick Waldron <[hidden email]>
>> wrote:
>> > While this is all true, the simple answer is:
>> >
>> > var a = 1, b = 2, c = 3;
>> > a < b < c; // true
>> >
>> > is already valid JavaScript and can't be co-opted to express new runtime
>> > evaluation semantics.
>>
>> Well, that's a bad example, because it's true with chained operators
>> too.  Let c = 1.5, though, and you get different behavior.
>
> It doesn't matter if you think my example is a "bad example", it's a valid
> expression per the language's existing grammar.

It certainly does, because we don't expose the parsing directly.  If
we change the interpretation of a piece of code, but it outputs the
same or compatible values, we're fine.  It's only when the observable
results change incompatibly that we have to worry.  In your example,
you get a "true" regardless of the interpretation, which means you're
not demonstrating a problem with changing the interpretation.

You have completely missed my point, please refer to the grammar specification that has existed since the first edition, published in 1997:

MultiplicativeExpression :
    UnaryExpression
    MultiplicativeExpression * UnaryExpression
    MultiplicativeExpression / UnaryExpression
    MultiplicativeExpression % UnaryExpression

AdditiveExpression :
    MultiplicativeExpression
    AdditiveExpression + MultiplicativeExpression
    AdditiveExpression - MultiplicativeExpression

ShiftExpression :
    AdditiveExpression
    ShiftExpression << AdditiveExpression
    ShiftExpression >> AdditiveExpression
    ShiftExpression >>> AdditiveExpression

RelationalExpression :
    ShiftExpression
    RelationalExpression < ShiftExpression
    RelationalExpression > ShiftExpression
    RelationalExpression <= ShiftExpression
    RelationalExpression >= ShiftExpression
    RelationalExpression instanceof ShiftExpression
    RelationalExpression in ShiftExpression

EqualityExpression :
    RelationalExpression
    EqualityExpression == RelationalExpression
    EqualityExpression != RelationalExpression
    EqualityExpression === RelationalExpression (ES3+)
    EqualityExpression !== RelationalExpression (ES3+)


Unambiguously and in no uncertain terms, the following is a completely valid expression (ie. will not throw a SyntaxError exception):

100 % 1 < 1e1 > 0xff - 5 + (+5) < 10 > 1.5 - 1..toString() === (function() {}()) !== parseInt(1, 10) * 1 | 0 >>> 1; 
// 1

It doesn't matter if the parsing isn't exposed, or broken in the first place, or a bad example, or not what you want, there is a formally defined grammar in a published standard. Hopefully I've cleared up any remaining questions or previously unclear points. 


Rick


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Chained comparisons from Python and CoffeeScript

Tab Atkins Jr.
On Fri, Jul 19, 2013 at 4:18 PM, Rick Waldron <[hidden email]> wrote:
> It doesn't matter if the parsing isn't exposed, or broken in the first
> place, or a bad example, or not what you want, there is a formally defined
> grammar in a published standard. Hopefully I've cleared up any remaining
> questions or previously unclear points.

You seem to be stating that once something's been published for a
while, it's frozen.  In reality, only the web-exposed parts are, and
then only the parts that the web actually depends on.  We can
potentially change *everything else*.

Thinking anything else is harmful, as it means you avoid thinking
about possible good ideas just because you've arbitrarily ruled out
certain classes of changes, despite there being no reason to avoid
that change.

Standards exist for the sole purpose of helping interoperability,
which we like because it makes it easier to do cool things.  Don't put
them on a pedestal they don't deserve.

~TJ
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Chained comparisons from Python and CoffeeScript

Claus Reinke
In reply to this post by Andy Earnshaw-2
> I'd like to see this implemented, at least for greater/less than (-or equal
> to).
>
>    a < b < c
>    a <= b <= c
>
> Desugars to
>
>    a < b && b < c
>    a <= b && b <= c

As a workaround, consider that ES6 arrow functions are going to
make something like this readable:

    function sortedBy(op,...args) {
      for(var i=1; i<args.length; i++) {
        if (!op( args[i-1], args[i])) return false;
      }
      return true;
    }

    console.log( sortedBy( (a,b)=>a<b,  2,3,4) );  // true
    console.log( sortedBy( (a,b)=>a<b,  2,4,3) );  // false

    console.log( sortedBy( (a,b)=>a<b,  2,2,3) );  // false
    console.log( sortedBy( (a,b)=>a<=b, 2,2,3) );  // true

Claus
 
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Chained comparisons from Python and CoffeeScript

Brendan Eich-3
In reply to this post by Tab Atkins Jr.
Tab Atkins Jr. wrote:
> In reality, only the web-exposed parts are,

What is not web-exposed here, pray tell?

>   and
> then only the parts that the web actually depends on.

This is the part we can't determine. "The web" is not just the
Google-indexable (by what user agent?) part, but paywalled and intranet
content as well. I've written before that finding true positives helps
reject a proposed incompatible change, but finding no positives does not
prove that we can make the change.

Furthermore, the first browser to roll the dice and face breakage loses,
making implementors generally unwilling to take even likely-small risks.
This browser Prisoner's Dilemma can be helped by cooperation, e.g.,
among TC39ers, but even then only for a big enough payoff. See the
typeof null == "null" attempt early in ES6 development for an example.

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Chained comparisons from Python and CoffeeScript

Andy Earnshaw-2
On Mon, Jul 22, 2013 at 5:25 AM, Brendan Eich <[hidden email]> wrote:
 
This is the part we can't determine. "The web" is not just the Google-indexable (by what user agent?) part, but paywalled and intranet content as well. I've written before that finding true positives helps reject a proposed incompatible change, but finding no positives does not prove that we can make the change.

Furthermore, the first browser to roll the dice and face breakage loses, making implementors generally unwilling to take even likely-small risks. This browser Prisoner's Dilemma can be helped by cooperation, e.g., among TC39ers, but even then only for a big enough payoff. See the typeof null == "null" attempt early in ES6 development for an example.

typeof null == "null" is a different case though.  typeof is a requirement for checking the existence of pre-declared variables, so you could expect something like, if (typeof someVar === "object" && someVar === null), to appear at least in a few places on the web.  Tab's saying that this proposal wouldn't break much (if anything) because code isn't written like this anywhere: it wouldn't be readable or reliable.  Writing a < b < c in ES<=5 would be either stupidity or ignorance (in the case of the latter then this proposal would probably fix more code than it breaks).  For equality, there might be a problem where code is written like, if (a === b === true), where a and b are something other than booleans.  I could maybe see an outside chance that this appears somewhere on the web or an intranet, but maybe there's a way we can deal with it so it doesn't break backwards compatibility.

"use chained comparisons";, anyone? ;-)

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Chained comparisons from Python and CoffeeScript

Bjoern Hoehrmann
* Andy Earnshaw wrote:
>typeof null == "null" is a different case though.  typeof is a requirement
>for checking the existence of pre-declared variables, so you could expect
>something like, if (typeof someVar === "object" && someVar === null), to
>appear at least in a few places on the web.  Tab's saying that this
>proposal wouldn't break much (if anything) because code isn't written like
>this anywhere: it wouldn't be readable or reliable.  Writing a < b < c in
>ES<=5 would be either stupidity or ignorance (in the case of the latter
>then this proposal would probably fix more code than it breaks).

If that code is interpreted reliably and the behavior is desired, there
is no reason to assume that e.g. code obfuscators would not produce it.
--
Björn Höhrmann · mailto:[hidden email] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Chained comparisons from Python and CoffeeScript

Claude Pache
In reply to this post by Andy Earnshaw-2
Two (or three) remarks:

(1) The following expressions are perfectly reasonable, where a, b, c, d are variables holding numbers, and y is a variable (not a literal) holding a boolean:
       
        a < b == y
        a < b == c < d

and even (although it demands some imagination):

        a < b <= y

where x <= y is a hackish way to express the so-called material implication (x → y) as defined in: http://en.wikipedia.org/wiki/Boolean_algebra#Derived_operations

Even if we ignore the last expression, it would be surprising (for, e.g., people used to Python), if we change the meaning of `a < b <= y` but not the one of `a < b == c < d`, so we are probably bound to change the meaning of very reasonable expressions anyway.

(2) If we change the meaning of `a < b < c`, then someone will use

        var a = 1, b = 2, c = 3;
        a < b < c; // true

in newer browsers, then check

        var a = 1, b = 2, c = 3;
        a < b < c; // true

in older browsers, and will fail to notice that their code is broken. In order to mitigate that hazard (supposing we want to make the breaking change anyway), we may want to invalidate expressions like `a < b < c` in ES6 (throwing a Syntax Error) and redefine their meaning in ES7.

> "use chained comparisons";, anyone? ;-)


(3) Instead of a "use chained comparisons" directive, I dream of an implicit "use perfect language" directive, where (1) typeof null === "null", (2) wrapper objects around primitives do not exist, (3) chained comparisons are implemented, (4) Date objects are not Y2K-broken by design, (5) Date objects are compared by value, (6) concatenation and addition are not conflated into one operator, (7) I am able to make coffee from within my preferred browser. :-)

—Claude

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Chained comparisons from Python and CoffeeScript

Andy Earnshaw-2
In reply to this post by Bjoern Hoehrmann
On Mon, Jul 22, 2013 at 2:08 PM, Bjoern Hoehrmann <[hidden email]> wrote:
If that code is interpreted reliably and the behavior is desired, there
is no reason to assume that e.g. code obfuscators would not produce it.
Perhaps, but I think it's highly unlikely.  It doesn't offer much obfuscation, considering that any third operand would certainly be truthy if the operator was greater than and falsy if the operator was less than.

On Mon, Jul 22, 2013 at 2:24 PM, Claude Pache <[hidden email]> wrote:
Even if we ignore the last expression, it would be surprising (for, e.g., people used to Python), if we change the meaning of `a < b <= y` but not the one of `a < b == c < d`, so we are probably bound to change the meaning of very reasonable expressions anyway.

Well, as Tab pointed out, comparison operators have the same precedence in Python, whereas in JavaScript the equality operators have a lower precedence.  So a < b == c < d is the same as (a < b) == (c < d).  Only operators with the same precedence could be chained, where's the confusion in that?  Python users still have to learn the same stuff when writing JavaScript.
 
(2) If we change the meaning of `a < b < c`, then someone will use

        var a = 1, b = 2, c = 3;
        a < b < c; // true

in newer browsers, then check

        var a = 1, b = 2, c = 3;
        a < b < c; // true

in older browsers, and will fail to notice that their code is broken. In order to mitigate that hazard (supposing we want to make the breaking change anyway), we may want to invalidate expressions like `a < b < c` in ES6 (throwing a Syntax Error) and redefine their meaning in ES7.

Yeah, I can see this being a problem.  Invalidating in preparation to redefine doesn't sound like a great solution, though, because you'd still have the same problem when the next specification rolls around.  Opt-in sounds like a better solution, if pragmas are to be entered into the specification then it could even become part of 

    use strict;

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Chained comparisons from Python and CoffeeScript

Domenic Denicola-2
From: Andy Earnshaw [[hidden email]]
> if pragmas are to be entered into the specification

They are not.

> then it could even become part of
>    use strict;

Or even better: it could become part of `./andys-transpiler myfile.andy`.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Chained comparisons from Python and CoffeeScript

Tab Atkins Jr.
In reply to this post by Brendan Eich-3
On Sun, Jul 21, 2013 at 9:25 PM, Brendan Eich <[hidden email]> wrote:
> Tab Atkins Jr. wrote:
>> In reality, only the web-exposed parts are,
>
> What is not web-exposed here, pray tell?

The parser itself.  Only the results of the parser are, in terms of
observable program behavior and presence/absence of syntax errors.

>>   and
>> then only the parts that the web actually depends on.
>
> This is the part we can't determine. "The web" is not just the
> Google-indexable (by what user agent?) part, but paywalled and intranet
> content as well. I've written before that finding true positives helps
> reject a proposed incompatible change, but finding no positives does not
> prove that we can make the change.
>
> Furthermore, the first browser to roll the dice and face breakage loses,
> making implementors generally unwilling to take even likely-small risks.
> This browser Prisoner's Dilemma can be helped by cooperation, e.g., among
> TC39ers, but even then only for a big enough payoff. See the typeof null ==
> "null" attempt early in ES6 development for an example.

Preaching to the choir, buddy - I've been standardsing for quite a
while too.  I'm not stating an opinion either way on whether this
change would be possible, I'm just pushing back on Rick's incorrect
statements about the primacy of an existing standard.  Gotta keep good
brain hygiene, you know.

~TJ
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Chained comparisons from Python and CoffeeScript

Claude Pache
In reply to this post by Andy Earnshaw-2

Le 22 juil. 2013 à 17:55, Andy Earnshaw <[hidden email]> a écrit :

On Mon, Jul 22, 2013 at 2:24 PM, Claude Pache <[hidden email]> wrote:
Even if we ignore the last expression, it would be surprising (for, e.g., people used to Python), if we change the meaning of `a < b <= y` but not the one of `a < b == c < d`, so we are probably bound to change the meaning of very reasonable expressions anyway.

Well, as Tab pointed out, comparison operators have the same precedence in Python, whereas in JavaScript the equality operators have a lower precedence.  So a < b == c < d is the same as (a < b) == (c < d).  Only operators with the same precedence could be chained, where's the confusion in that?  Python users still have to learn the same stuff when writing JavaScript.

In the three languages you have cited (Python, Perl6 and CoffeeScript), all comparison operators (both equality and inequality ones) can be chained together. Introducing only half-baked chaining in ES will be quite confusing. If we dare introduce chaining, which is already a disruptive change, we ought to go until the end and to adjust the precedence of relational and equality operators as well. (Actually, we would introduce an n-ary comparison operator.)

—Claude

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Chained comparisons from Python and CoffeeScript

Brendan Eich-3
In reply to this post by Andy Earnshaw-2
Andy Earnshaw wrote:

> On Mon, Jul 22, 2013 at 5:25 AM, Brendan Eich <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     This is the part we can't determine. "The web" is not just the
>     Google-indexable (by what user agent?) part, but paywalled and
>     intranet content as well. I've written before that finding true
>     positives helps reject a proposed incompatible change, but finding
>     no positives does not prove that we can make the change.
>
>     Furthermore, the first browser to roll the dice and face breakage
>     loses, making implementors generally unwilling to take even
>     likely-small risks. This browser Prisoner's Dilemma can be helped
>     by cooperation, e.g., among TC39ers, but even then only for a big
>     enough payoff. See the typeof null == "null" attempt early in ES6
>     development for an example.
>
>
> typeof null == "null" is a different case though.  typeof is a
> requirement for checking the existence of pre-declared variables, so
> you could expect something like, if (typeof someVar === "object" &&
> someVar === null), to appear at least in a few places on the web.
>  Tab's saying that this proposal wouldn't break much (if anything)
> because code isn't written like this anywhere: it wouldn't be readable
> or reliable.  Writing a < b < c in ES<=5 would be either stupidity or
> ignorance (in the case of the latter then this proposal would probably
> fix more code than it breaks).

You're committing a category error here. It doesn't matter *why* someone
does something on the web, it matters *how much* the standard semantics
are required by "working" code (scare quotes on purpose).

In other words, you can't reason about this _a priori_ only and reach a
conclusion that "we can get away with a breaking change". Such "we can
get away with" claims require _a posteriori_ experiments and
potentially-market-share-losing results, too.

>  For equality, there might be a problem where code is written like, if
> (a === b === true), where a and b are something other than booleans.
>  I could maybe see an outside chance that this appears somewhere on
> the web or an intranet, but maybe there's a way we can deal with it so
> it doesn't break backwards compatibility.
>
> "use chained comparisons";, anyone? ;-)

We could add more pseudo-pragmas but they must not add runtime checks
(so this one would be ok by that constraint), and we'll have a wicked
fight justifying any additions that aren't strongly motivated.

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Chained comparisons from Python and CoffeeScript

Brendan Eich-3
In reply to this post by Tab Atkins Jr.
Tab Atkins Jr. wrote:
> On Sun, Jul 21, 2013 at 9:25 PM, Brendan Eich<[hidden email]>  wrote:
>> Tab Atkins Jr. wrote:
>>> In reality, only the web-exposed parts are,
>> What is not web-exposed here, pray tell?
>
> The parser itself.  Only the results of the parser are, in terms of
> observable program behavior and presence/absence of syntax errors.

This is irrelevant, since the change you are proposing is a
compatibility-breaking one, even though parse trees are not yet reflectable.

>>>    and
>>> then only the parts that the web actually depends on.
>> This is the part we can't determine. "The web" is not just the
>> Google-indexable (by what user agent?) part, but paywalled and intranet
>> content as well. I've written before that finding true positives helps
>> reject a proposed incompatible change, but finding no positives does not
>> prove that we can make the change.
>>
>> Furthermore, the first browser to roll the dice and face breakage loses,
>> making implementors generally unwilling to take even likely-small risks.
>> This browser Prisoner's Dilemma can be helped by cooperation, e.g., among
>> TC39ers, but even then only for a big enough payoff. See the typeof null ==
>> "null" attempt early in ES6 development for an example.
>
> Preaching to the choir, buddy - I've been standardsing for quite a
> while too.

So why were you preaching at Rick? I didn't want to reply, but at some
point the one-sided arguing got to be too much.

Look, you're proposing an incompatible change, akin to typeof null's
result change. It doesn't matter why people might write code you'd
break, it matters how much code exists. That's an empirical question.
Exhorting people here does nothing but annoy some of us.

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12