Re: A few arrow function specification issues

Allen Wirfs-Brock wrote: Back to the original point, which was that making strict mode delete throw when applied to a non-configurable property is not significantly higher integrity than the non-strict behavior of returning false when a property can not be deleted. http://www.flickr.com/photos

Re: A few arrow function specification issues

On Apr 24, 2012, at 1:28 PM, Brendan Eich wrote: > Douglas Crockford wrote: >> On 4/23/2012 6:41 PM, Mark S. Miller wrote: >>> On Mon, Apr 23, 2012 at 6:30 PM, Allen Wirfs-Brock >>> mailto:al...@wirfs-brock.com>> wrote: >>> >>> >>>The point is that much of what is done on the web is not hig

Re: A few arrow function specification issues

On 4/24/2012 1:28 PM, Brendan Eich wrote: http://www.imdb.com/title/tt0076759/quotes?qt=qt0440727 http://www.imdb.com/title/tt0121766/quotes?qt=qt0333083 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: A few arrow function specification issues

Douglas Crockford wrote: On 4/23/2012 6:41 PM, Mark S. Miller wrote: On Mon, Apr 23, 2012 at 6:30 PM, Allen Wirfs-Brock mailto:al...@wirfs-brock.com>> wrote: The point is that much of what is done on the web is not high integrity computation. It is essential that high integrity be

Re: Re: A few arrow function specification issues

On 4/23/2012 6:41 PM, Mark S. Miller wrote: On Mon, Apr 23, 2012 at 6:30 PM, Allen Wirfs-Brock mailto:al...@wirfs-brock.com>> wrote: The point is that much of what is done on the web is not high integrity computation. It is essential that high integrity be possible, when it is requi

Re: A few arrow function specification issues

This is why I posited an explicit switch. Right now we're all talking about secondary triggers for a very important component. Why isn't it just an explicit choice? Why can't I install a foot gun where I know I have foot armor plating? The goal being that when my users, without such armor, are less

Re: A few arrow function specification issues

+1 High integrity engineering of components supports low integrity integration essential for low cost adaptable systems. We have scripting for the same reason we carpenters. We could build a house using a computer milling machine but no one could afford it; we don't want JavaScript to enforce high

Re: A few arrow function specification issues

On Mon, Apr 23, 2012 at 6:30 PM, Allen Wirfs-Brock wrote: > > The point is that much of what is done on the web is not high integrity > computation. It is essential that high integrity be possible, when it is > required. But forcing all computation into the high integrity category > seems like as

Re: A few arrow function specification issues

On Apr 23, 2012, at 6:09 PM, Mark S. Miller wrote: > > > On Mon, Apr 23, 2012 at 5:47 PM, Allen Wirfs-Brock > wrote: > >> >> ... > > The delete issue is very much along the lines of what I was referring to in > another thread[3] today regarding "failure oblivious computing". I just > do

Re: A few arrow function specification issues

On Mon, Apr 23, 2012 at 5:47 PM, Allen Wirfs-Brock wrote: > > On Apr 23, 2012, at 4:59 PM, Domenic Denicola wrote: > > As a day-to-day user who was not using strict until recently (stubborn > other team member for the loss), I can say that moving to strict was much > more a "cleanup" experience th

Re: A few arrow function specification issues

On Apr 23, 2012, at 4:59 PM, Domenic Denicola wrote: > As a day-to-day user who was not using strict until recently (stubborn other > team member for the loss), I can say that moving to strict was much more a > "cleanup" experience than a "mode" experience, with only a few small > exceptions:

Re: A few arrow function specification issues

oughout the codebase, in > fact, due to using an XHR+`eval` module loader that can insert the `"use > strict"` pragma before `eval`ing. > > -Original Message- > From: es-discuss-boun...@mozilla.org [mailto:es-discuss- > boun...@mozilla.org] On Behalf Of David Herman

Re: A few arrow function specification issues

`var` in eval I meant (and `const` in Narcissus's case) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: A few arrow function specification issues

Strict mode delete non-configurable is one of the only offenders on the "this really shouldn't be an error" list. The "useful functionality no longer allowed" list is a couple of key things: caller for debug tracing, and `var` in define. The latter was an issue with Narcissus running in V8 --harmon

Re: A few arrow function specification issues

codebase, in > fact, due to using an XHR+`eval` module loader that can insert the `"use > strict"` pragma before `eval`ing. > > > -Original Message- > > From: es-discuss-boun...@mozilla.org [mailto:es-discuss- > > boun...@mozilla.org (mailto:boun...@mozilla.org)] O

RE: A few arrow function specification issues

ailto:es-discuss- > boun...@mozilla.org] On Behalf Of David Herman > Sent: Monday, April 23, 2012 19:11 > To: Brendan Eich > Cc: es-discuss > Subject: Re: A few arrow function specification issues > > On Apr 23, 2012, at 2:44 PM, Brendan Eich wrote: > > > Brendan Eic

Re: A few arrow function specification issues

On Apr 23, 2012, at 2:44 PM, Brendan Eich wrote: > Brendan Eich wrote: >> Without arguments runtime semantic shifts, and with |this| lexical, there >> aren't many strict mode changes left IIRC, and they are pretty edgy edge >> cases. > > True enough, but I hang tough on wanting arrows to imply

Re: A few arrow function specification issues

On Apr 23, 2012, at 2:45 PM, David Herman wrote: > You cannot distinguish whether a function was called as a method, as a > function, or via .call/.apply. There's no way to tell. PS Well, there's stack inspection, but we're all grownups here. Dave __

Re: A few arrow function specification issues

On Apr 21, 2012, at 1:38 PM, Angus Croll wrote: > >>a function shouldn’t work radically (and silently!) different depending on > >>how it is invoked > > every current JS function behaves exactly this way :-) No, not at all. What Axel is saying is that you're proposing a new distinction that *d

Re: A few arrow function specification issues

Brendan Eich wrote: Without arguments runtime semantic shifts, and with |this| lexical, there aren't many strict mode changes left IIRC, and they are pretty edgy edge cases. Dave Herman pointed out the shift for |this|-binding in function nested in arrow, under the proposal that arrow implie

Re: caller poison pills, revisited (Was: A few arrow function specification issues)

On Mon, Apr 23, 2012 at 11:42 AM, Brendan Eich wrote: > The threat (not sure how real) is not a string telling the backtrace, it's > an object reference to an ancestor function in the call stack. > The ancestor function leak is vastly worse than the backtrace into leak, but both are real. http:

Re: caller poison pills, revisited (Was: A few arrow function specification issues)

[+google-caja-discuss] On Mon, Apr 23, 2012 at 11:13 AM, Allen Wirfs-Brock wrote: > I'd like MarkM or other SES advocates to propose language that expression > the restriction they need. > +1. This was actually discussed at the time for ES5. We went with the poison pill approach because at the

Re: caller poison pills, revisited (Was: A few arrow function specification issues)

On Mon, Apr 23, 2012 at 11:15 AM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: > >> This raises the issue that ES5.1 overlooked poisoning caller/arguments >> for Function.prototype. Only function object created using the algorithm >> in 13.2 have the the poison pill properties and Function.pro

Re: caller poison pills, revisited (Was: A few arrow function specification issues)

The threat (not sure how real) is not a string telling the backtrace, it's an object reference to an ancestor function in the call stack. /be Domenic Denicola wrote: I'm becoming increasing convinced that the poison pill approach to securing the caller chain is a poor approach. We keep findi

Re: caller poison pills, revisited (Was: A few arrow function specification issues)

> I'm becoming increasing convinced that the poison pill approach to securing > the caller chain is a poor approach. We keep finding leaks in and it does > nothing to prevent implementation from inventing new ways to expose the > stating they are trying to hide. I now think we would be better o

Re: caller poison pills, revisited (Was: A few arrow function specification issues)

Allen Wirfs-Brock wrote: caller and arguments properties on functions are a non-standard extension, Right you are: js> Function.prototype.caller null js> Function.prototype.arguments null and of course this is heap not code, so strictness doesn't enter into it. Still happy to change our impl

Re: caller poison pills, revisited (Was: A few arrow function specification issues)

On Apr 23, 2012, at 11:15 AM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: >> This raises the issue that ES5.1 overlooked poisoning caller/arguments for >> Function.prototype. Only function object created using the algorithm in >> 13.2 have the the poison pill properties and Function.prototy

Re: caller poison pills, revisited (Was: A few arrow function specification issues)

Allen Wirfs-Brock wrote: This raises the issue that ES5.1 overlooked poisoning caller/arguments for Function.prototype. Only function object created using the algorithm in 13.2 have the the poison pill properties and Function.prototype is not specified using 13.2. Function.prototype is speci

caller poison pills, revisited (Was: A few arrow function specification issues)

On Apr 23, 2012, at 10:18 AM, Brandon Benvie wrote: > > > 6) Do arrow functions need to have per instance "caller" and "arguments" > > poison pill properties? > > > > I propose no, because they are a new feature. But we can include a NOTE > > warning against providing their non-standard legacy

Re: A few arrow function specification issues

Brandon Benvie wrote: > 6) Do arrow functions need to have per instance "caller" and "arguments" poison pill properties? > > I propose no, because they are a new feature. But we can include a NOTE warning against providing their non-standard legacy implementation. F

Re: A few arrow function specification issues

Allen Wirfs-Brock wrote: On Apr 23, 2012, at 8:19 AM, Brendan Eich wrote: Andreas Rossberg wrote: To be honest, that suggestion confirms one of my fears about "1JS" -- ending up with a more complicated language with ad-hoc rules about which mode applies in which context. Please let's try to re

Re: A few arrow function specification issues

> > > > 6) Do arrow functions need to have per instance "caller" and "arguments" > poison pill properties? > > > > I propose no, because they are a new feature. But we can include a NOTE > warning against providing their non-standard legacy implementation. > > For simplicity and uniformity, I'd kee

Re: A few arrow function specification issues

On Apr 23, 2012, at 8:19 AM, Brendan Eich wrote: > Andreas Rossberg wrote: >> To be honest, that suggestion confirms one of my fears about "1JS" -- >> ending up with a more complicated language with ad-hoc rules about >> which mode applies in which context. Please let's try to resist the >> tempt

Re: A few arrow function specification issues

Andreas Rossberg wrote: On 21 April 2012 01:22, Allen Wirfs-Brock wrote: 7) All of the above questions also apply to functions defined using concise method syntax in object literals or classes. Should the same answers apply to them? I'd prefer if concise method syntax stayed simple syntact

Re: A few arrow function specification issues

Andreas Rossberg wrote: To be honest, that suggestion confirms one of my fears about "1JS" -- ending up with a more complicated language with ad-hoc rules about which mode applies in which context. Please let's try to resist the temptation. As much as I would like to encourage strict mode, I thin

Re: A few arrow function specification issues

> > I'd prefer if concise method syntax stayed simple syntactic sugar for > functions. Methods obviously need dynamic this. If you combine that > with changes like the above, then you have implicitly introduced a > third kind of function that cannot be described as (simple) syntactic > sugar for an

Re: A few arrow function specification issues

On Apr 23, 2012, at 10:15 AM, Andreas Rossberg wrote: > On 21 April 2012 01:22, Allen Wirfs-Brock wrote: >> Here are a few design alternates that have come up as I work the >> specification draft for arrow functions >> >> 1) Always strict? Should all arrow functions be considered strict functi

Re: A few arrow function specification issues

On 21 April 2012 01:22, Allen Wirfs-Brock wrote: > Here are a few design alternates that have come up as I work the > specification draft for arrow functions > > 1) Always strict? Should all arrow functions be considered strict functions? > > Pros > It's a new syntactic form, so it is it easy to

Re: A few arrow function specification issues

Angus Croll wrote: On Sat, Apr 21, 2012 at 1:56 PM, Axel Rauschmayer mailto:a...@rauschma.de>> wrote: Counter-question: Isn’t it clear when you create a function whether it is going to be a non-method function or a method? It's clear to the implementer - Its not clear to a function

Re: A few arrow function specification issues

> Using `=>` but being forced to using `function` anytime I want dynamic this > just doesn't work. That may be the crux of the matter. I’d say: In new code, use a method definition any time you want dynamic `this`. In old code, use a function expression. -- Dr. Axel Rauschmayer a...@rauschma.

Re: A few arrow function specification issues

> > I understand your argument, but I think it is more important to be able to > switch in full to the new function operator(s), not sometimes one, other > times the other. > Why? Arrow functions and traditional functions serve different semantic purposes. Why is it important to you that we esse

Re: A few arrow function specification issues

> I would argue that – in ES.next – whenever a function is passed as an > argument, one should always assume that it is a non-method function and > completely ignore `this`. > > This makes me sad. Seems like functions are going to be a little less first > class than they were before - and for f

Re: A few arrow function specification issues

Angus Croll wrote: On Sat, Apr 21, 2012 at 3:06 PM, Axel Rauschmayer > wrote: On Sat, Apr 21, 2012 at 1:56 PM, Axel Rauschmayer mailto:a...@rauschma.de>> wrote: Counter-question: Isn’t it clear when you create a function whether it is going to b

Re: A few arrow function specification issues

On Sat, Apr 21, 2012 at 3:06 PM, Axel Rauschmayer wrote: > On Sat, Apr 21, 2012 at 1:56 PM, Axel Rauschmayer wrote: > >> Counter-question: Isn’t it clear when you create a function whether it is >> going to be a non-method function or a method? >> > > It's clear to the implementer - Its not clear

Re: A few arrow function specification issues

> On Sat, Apr 21, 2012 at 1:56 PM, Axel Rauschmayer wrote: > Counter-question: Isn’t it clear when you create a function whether it is > going to be a non-method function or a method? > > It's clear to the implementer - Its not clear to a function that gets it as > an argument - unless fn.proto

Re: A few arrow function specification issues

On Sat, Apr 21, 2012 at 1:56 PM, Axel Rauschmayer wrote: > Counter-question: Isn’t it clear when you create a function whether it is > going to be a non-method function or a method? > It's clear to the implementer - Its not clear to a function that gets it as an argument - unless fn.prototype is

Re: A few arrow function specification issues

> >>a function shouldn’t work radically (and silently!) different depending on > >>how it is invoked > > every current JS function behaves exactly this way :-) `this` when not invoking a function as a method: 1. Bearable: this === undefined 2. Nasty: this === window 3. Very nasty: lexical this

Re: A few arrow function specification issues

>>a function shouldn’t work radically (and silently!) different depending on how it is invoked every current JS function behaves exactly this way :-) I'm painfully aware that I sound like a broken record on this, but introducing a hard-bound function option while continuing to suport dynamic-boun

Re: A few arrow function specification issues

d skinny arrow. On Sat, Apr 21, 2012 at 1:17 PM, Domenic Denicola < dome...@domenicdenicola.com> wrote: > > -Original Message- > > From: es-discuss-boun...@mozilla.org [mailto:es-discuss- > > boun...@mozilla.org] On Behalf Of Angus Croll > > Sent: Saturday, Ap

Re: A few arrow function specification issues

> I am in agreement with Angus on this one. > > If there is no skinny arrow, hard |this| binding should not be part of the > spec. Fat arrow functions should default to lexical |this|, but if there is > no skinny arrow, it should not be a hard binding and call/apply should be > allowed, as well

RE: A few arrow function specification issues

> -Original Message- > From: es-discuss-boun...@mozilla.org [mailto:es-discuss- > boun...@mozilla.org] On Behalf Of Angus Croll > Sent: Saturday, April 21, 2012 16:03 > To: Allen Wirfs-Brock > Cc: es-discuss > Subject: Re: A few arrow function specification issues >

Re: A few arrow function specification issues

I am in agreement with Angus on this one. If there is no skinny arrow, hard |this| binding should not be part of the spec. Fat arrow functions should default to lexical |this|, but if there is no skinny arrow, it should not be a hard binding and call/apply should be allowed, as well as bind, On

Re: A few arrow function specification issues

>>4) Should it be a dynamic error to try to use apply/call to set the this binding of an arrow function. >>Cons >>To much existing code speculatively binding the this value when invoking a function. >>I propose that call/apply simply ignore the this value when invoked on an arrow function. What

Re: A few arrow function specification issues

Allen Wirfs-Brock wrote: 1) Always strict? Should all arrow functions be considered strict functions? Pros P1. It's a new syntactic form, so it is it easy to make it be an implicit opt-in to strict mode. P2. We generally want to encourage use of strict mode. P3. If not, there would no way to to

A few arrow function specification issues

Here are a few design alternates that have come up as I work the specification draft for arrow functions 1) Always strict? Should all arrow functions be considered strict functions? Pros It's a new syntactic form, so it is it easy to make it be an implicit opt-in to strict mode. We generally wa