Fwd: Fix Left-Associative Compound Conditional Statements!!

## Left-Associative Compound Conditional Statements I would like the ability to compare many values in compound. As I do not see any real reason to avoid this, here is my proposal: Following [this document]( http://yehudakatz.com/2011/09/13/a-proposal-for-es-next-proposals/) (thanks @wykatz) ###

Re: Exponentiation operator precedence

Quick update from TC39 yesterday where Rick and I presented the Stage 3 Exponentiation Operator proposal: http://rwaldron.github.io/exponentiation-operator/ The current spec, revised to match precedent from all known programming languages that have exponentiation operators, binds -x^y =

Re: Fix Left-Associative Compound Conditional Statements!!

> > Actually, scratch that, its not even JUST a matter of convenience. A > simple evaluation in your developer console will tell you that this > currently evaluates inconveniently (I am avoiding the term "incorrectly" > here because it is not theoretically incorrect if we consider these >

Re: Fix Left-Associative Compound Conditional Statements!!

Isn't this logic theoretically broken? If any existing code is using it, the code that is using it is probably performing an invalid or inaccurate operation and therefore this would only break that code so much as it was already not functioning as expected? On Thu, Sep 24, 2015 at 10:40 AM, Kevin

Re: Fix Left-Associative Compound Conditional Statements!!

For an old discussion on the same subject, see: https://esdiscuss.org/topic/chained-comparisons-from-python-and-coffeescript —Claude___ es-discuss mailing list

Re: Exponentiation operator precedence

[Apologies for resending, trying to fix formatting of grammar excerpts. /be] Quick update from TC39 yesterday where Rick and I presented the Stage 3 Exponentiation Operator proposal: http://rwaldron.github.io/exponentiation-operator/ The current spec, revised to match precedent from all

Re: Exponentiation operator precedence

Here's a nicely formatted jsbin version of my message: http://jsbin.com/bihilaveda Sorry about the mess, mail user agents (at least Postbox) and archive software do not like explicit indentation. /be ___ es-discuss mailing list

Re: Fix Left-Associative Compound Conditional Statements!!

On Thu, Sep 24, 2015 at 4:50 PM, Joseph Groseclose wrote: > Isn't this logic theoretically broken? If any existing code is using it, > the code that is using it is probably performing an invalid or inaccurate > operation and therefore this would only break that code so much

Re: Exponentiation operator precedence

Even nicer: http://jsbin.com/baquqokujo I hate email. /be Brendan Eich wrote: Here's a nicely formatted jsbin version of my message: http://jsbin.com/bihilaveda Sorry about the mess, mail user agents (at least Postbox) and archive software do not like explicit indentation. /be

Re: Exponentiation operator precedence

I like #4. Normally in a situation like this I would still argue for #1. #4 is a complicated special case that breaks the normal pattern of operator precedence elsewhere in the language. The need for ** is not great enough to justify introducing a new special case for users to learn. However, in

Re: Exponentiation operator precedence

On 24 September 2015 at 17:19, Brendan Eich wrote: > Even nicer: > > http://jsbin.com/baquqokujo > > I hate email. You are holding it wrong. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org

Re: Exponentiation operator precedence

I won't try to guess where the rendering problem is, but see the attached screenshots. This is how I'm seeing your page on my Chrome and Firefox. On Thu, Sep 24, 2015 at 8:19 AM, Brendan Eich wrote: > Even nicer: > > http://jsbin.com/baquqokujo > > I hate email. > > /be > >

Re: Fix Left-Associative Compound Conditional Statements!!

At some length I see, heh. Alright, I guess that just about sums it up. On Thu, Sep 24, 2015 at 11:01 AM, Claude Pache wrote: > For an old discussion on the same subject, see: > > > https://esdiscuss.org/topic/chained-comparisons-from-python-and-coffeescript > > —Claude

Object.clone - not quite a proposal

I'm horrid with proposals, but this seems like a missing hole and I couldn't find a previous mention of it. Looking at the Object support methods it seems that the only thing that doesn't exist is a (simple) way to clone an object and all of its members. Ideally would allow creation of immutable

Re: Exponentiation operator precedence

On Thu, Sep 24, 2015 at 11:08 AM, Claude Pache wrote: > > Le 24 sept. 2015 à 16:11, Brendan Eich a écrit : > > And indeed apart from dot (a special form whose right operand must be a > lexical identifier-name) and square brackets (which isn't an

Re: Exponentiation operator precedence

I object to #4. Disallowing perfectly reasonable math expressions (Claude's is a good example) makes this operator too surprising to include in the language. From: Brendan Eich Sent: Sep 24, 2015 13:18 To: Mark S. Miller; Claude Pache Cc: es-discuss Subject: Re:

Re: Object.clone - not quite a proposal

return src.map((item)=>clone(item)); probably return src.map(Object.clone); would do, if it accepts only one argument. It seems that HTML nodes are missing (through document.createXXX) and it relies on `instanceof` which works for me but it doesn't as proposal 'cause incompatible cross realms.

Re: Object.clone - not quite a proposal

The code was only meant to be a better explanation of the goal, but yes it would have to take into account getters, setters, etc... Actually it was a copy/paste edit of some code we use for cloning (deserialized) JSON objects for API reproduction. There is an omit stage that was removed and

Re: Exponentiation operator precedence

Right. It's confusing because (as opposed to Math), ** is not a superscripting operator whose typography suggests higher precedence than -, and this matters for the sign of the result when exponentiating. Claude, the Math folks won't often need to negate the result, but when they do, they'll have

Re: Object.clone - not quite a proposal

Cloning is not a trivial matter. You may be interested in these previous discussions before discussing further: - https://esdiscuss.org/topic/the-structured-clone-wars - https://esdiscuss.org/topic/structured-clones -

Re: Object.clone - not quite a proposal

> Le 24 sept. 2015 à 19:58, Andrea Giammarchi a > écrit : > > Last, but not least, one does not simply assign properties in JavaScript. If > you want to clone you don't want to miss possible get/set accessors in the > process, you don't want to miss

Re: Exponentiation operator precedence

Sez you! :-P Seriously, the problem you are dismissing implicitly (bad form :-/) is the one we discussed yesterday, which I've stated explicitly twice now: the typography and plain sense of JS-in-itself suggests unary minus binds tighter than any binary connective (including **). Saying "Math!"

Re: Exponentiation operator precedence

> Le 24 sept. 2015 à 22:20, Brendan Eich a écrit : > > Sez you! :-P > > Seriously, the problem you are dismissing implicitly (bad form :-/) is the > one we discussed yesterday, which I've stated explicitly twice now: the > typography and plain sense of JS-in-itself

Re: Exponentiation operator precedence

The worry over the meaning of (- x ** y) arises not just due to conventions or inference from typography, but from intuitions based on limited knowledge. As Dave Herman pointed out yesterday, many programmers (most) do not have the full precedence and associativity set memorized. When in doubt,

Re: Exponentiation operator precedence

My preference is for 2, but I don't have objections to 4. Either works. Waldemar ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Exponentiation operator precedence

Thanks again to Brendan for taking time to write this up. And to Mark, thanks for reviewing this and expeditiously providing valuable feedback—it's greatly appreciated. Rick On Thu, Sep 24, 2015 at 8:27 AM Mark S. Miller wrote: > I won't try to guess where the rendering

Re: Exponentiation operator precedence

> Le 24 sept. 2015 à 16:11, Brendan Eich a écrit : > > And indeed apart from dot (a special form whose right operand must be a > lexical identifier-name) and square brackets (which isn't an infix operator > per se), unary operators bind tighter than binary in JS as in C

Re: Object.clone - not quite a proposal

Also, one reason I haven't used that, if you clone descriptors you do a shallow copy, not a deep one ;-) On Fri, Sep 25, 2015 at 2:31 AM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > Claude, you know that's actually *my* proposal, right? :P >

Re: Object.clone - not quite a proposal

Claude, you know that's actually *my* proposal, right? :P https://gist.github.com/WebReflection/9353781 But yeah, that's the spirit! On Thu, Sep 24, 2015 at 8:21 PM, Claude Pache wrote: > > Le 24 sept. 2015 à 19:58, Andrea Giammarchi > a