Re: ES6 doesn't need opt-in
On Thu, Jan 5, 2012 at 11:47 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: 1) program using only ES3 features and no use strict; 2) program using only ES5 strict features and saying use strict; 3) program using ES6-only features. Do these three programs operate in three different modes? If not, do #1 and #2 operate in the same mode, or do #2 and #3 operate in the same mode? It isn't about modes. #1 and #2 are ES5 programs and are processed as such (applying/not the appropriately strictness as per ES5) . #3 is an ES6 program is processed as such (including using the strict semantics that are universal to ES6). Ok, is there any observable difference between what you would have future browsers do, vs the equivalent mechanisms except that program #2 is categorized as an ES6 program and processed as such? If there is no observable difference, good. Then it's only a matter of how we describe an agreed semantics. If there is an observable difference, how is this not three modes? -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 5, 2012, at 10:38 PM, Luke Hoban wrote: ... # Why ‘implicit explicit opt-in’ doesn’t seem reasonable # The prevalent alternatives presented in this thread are variations of “implicit explicit opt-in”, where use of some new syntax causes some part of the code inside or outside of it to start behaving differently (breaking changes). I think in practice this will be very confusing. Take this: var x = typeof null; module { var y = typeof null; x == y // false! } Note that my most resent postings were suggesting a different form of implicit explicit opt-in: use of new syntax causes all of the code in the same source file to potentially behave differently var x = typeof null; module { var y = typeof null; x == y // -true! } In practice, I agree that we don't want to make such a breaking change for typeof. But this approach would allow to make strict mode semantics be implicit for any source file that uses any new ES6 syntactic features. Allen___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 6, 2012, at 12:00 AM, Mark S. Miller wrote: On Thu, Jan 5, 2012 at 11:47 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: 1) program using only ES3 features and no use strict; 2) program using only ES5 strict features and saying use strict; 3) program using ES6-only features. Do these three programs operate in three different modes? If not, do #1 and #2 operate in the same mode, or do #2 and #3 operate in the same mode? It isn't about modes. #1 and #2 are ES5 programs and are processed as such (applying/not the appropriately strictness as per ES5) . #3 is an ES6 program is processed as such (including using the strict semantics that are universal to ES6). Ok, is there any observable difference between what you would have future browsers do, vs the equivalent mechanisms except that program #2 is categorized as an ES6 program and processed as such? If there is no observable difference, good. Then it's only a matter of how we describe an agreed semantics. If there is an observable difference, how is this not three modes? There should be no observable difference. But the issue isn't how we described the (program) semantics. It is how we decide which semantics to apply. The tricky cases are thing like: function f(a) { arguments[0]=2; return a } print(f(1)); //2 if ES5, 1 if ES6 There is nothing in the source file that implies which specification to apply so for backwards computability a browser must default to interpreting such program as a ES5 program. Anything syntactically unique to ES5 (eg, use of a with statment) or ES6 (eg, use rest or spread) would force one interpretation or another Allen -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Fri, Jan 6, 2012 at 12:24 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: There should be no observable difference. But the issue isn't how we described the (program) semantics. It is how we decide which semantics to apply. Got it. It still gives the web only two modes, but has the huge benefit that the ES6 spec can avoid describing the semantics of non-strict code. Cool. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Improving Function.prototype.bind
same thing this does var bound = Object.bind(Object); bound.foo = capabilityBobShouldntGet; // who does this ? var HAH = bound.foo; ... so I am missing your point I guess ... but my proposal wants to return always same object for 99.9% of usage out there ... On Fri, Jan 6, 2012 at 8:55 AM, Mark S. Miller erig...@google.com wrote: In your proposal, what does this code sequence do: Object.boundTo(Object).foo = capabilityBobShouldntGet; var HAH = Object.boundTo(Object).foo; ? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Improving Function.prototype.bind
Le 05/01/2012 23:10, Andrea Giammarchi a écrit : leaks When a function has no strong reference, the associated entry in the first WeakMap (which is the second level of weakmap) can be GC'ed. When an object has no strong reference, all entries in second-level WeakMaps can be collected. I don't see any leaks. Assuming a GC with reachability, each bound function is kept only if both the function and the object are still in the environment (which is the minimum we need to achieve the functional goal). performances A native implementation can use a hash table using the 2 references as keys. I don't know to what extent it would be that much better. as example, are the first things I have in mind when I look at that code ( assuming I understand how WeakMap works there ) (...) My point is that Function.prototype.bind is used 90% of the time with context only, 10% with arguments, 0% as different object since nobody uses two bound functions to the same object, arguments a part. And you obviously have a one-year study crawling over 100,000 websites and 1000 node projects to back these numbers? Also, does use refer to the occurence of code written doing what you describe or occurence of run? All in all, let's not use numbers or quantifiers when there is no backing besides the experience of a few, because no reliable decision can really be taken based on that. Function.prototype.bind could have been implemented via libraries ( as Prototype did ) as well so I don't get your argument, sorry. I am suggesting a semantic improvement Object related but of course I can solve all missing real-nedeed things via a library ... you know what I mean? My point is that what can be solved efficiently should be by a library. I think the solution I've provided would be satifactory (you can obviously disagree). I'm more interested in ECMAScript solving problems that either can't be solved or not efficiently. This currently includes private names, weakmaps, modules, proxies, all the syntax sugar, binary data... David Regards On Thu, Jan 5, 2012 at 11:01 PM, David Bruant bruan...@gmail.com mailto:bruan...@gmail.com wrote: Hi Andrea, It seems that what you want can be implemented as a library [1] (actually you did it as well in your blog post). In this gist, a cache is used. In a nutshell, it is a '(function, object) - boundFunction' mapping. I used 2 levels of WeakMaps to achieve this. I don't think a native implementation could be that much more efficient neither in space nor time. Assuming my implementation does what you need, what would be the benefit of a native implementation over what I propose? David [1] https://gist.github.com/1567494 Le 05/01/2012 14:54, Andrea Giammarchi a écrit : I have thought it may be interesting to receive some comment here too ... so here the short summary: genericCallback.bind(sameObject) !== genericCallback.bind(sameObject) quite inconvenient for listeners and leading to uncomfortable patterns ( store the bound reference somewhere and get it back later ) plus bind, at the end of a function, where the topic is the context, looks more like a yoda statement function with context as this object rather than object as context of this function So, the proposal, is a simplified Object.prototype.boundTo ( or eventually, to avoid conflicts with bind signature Object.prototype.asContextOf ) where the action is object, as context, related, and the returned function is one and one only sameObject.boundTo(genericCallback) === sameObject.boundTo(genericCallback) or, if you prefer sameObject.asContextOf(genericCallback) === sameObject.asContextOf(genericCallback) Here the whole post with better examples plus the proposed solution that would be nice to have in JS.Next http://webreflection.blogspot.com/2012/01/improving-functionprototypebind.html Best Regards, Andrea Giammarchi ___ es-discuss mailing list es-discuss@mozilla.org mailto: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: Improving Function.prototype.bind
Such an implementation would be very slow and not efficient, because searching for a key in the boundFunctions weakmap would take time. It can be a polyfill solution but a new implementation need something better. I think the solution would be to create an invisible [[boundFunctions]] property for all objects containing a dictionnaryweakfunction, weakboundFunction of already-bound functions on the object. The implementation of bind would then be : - if objToBind is not a reference, create a new boundFunction and return it. - if objToBind.[[boundFunctions]] don't exist, create it. - else, check if it contains a key for functionToBind //when you are processing the dictionnary, remove obsolete entries you may find - if yes, check if the weak reference is alive - if yes, returns the boundFunction - create a new boundFunction and store it into objToBind.[[boundFunctions]] - return the newly created boundFunction Would that be possible? François -Message d'origine- From: Brendan Eich Sent: Friday, January 06, 2012 2:22 AM To: Andrea Giammarchi Cc: Axel Rauschmayer ; François REMY ; es-discuss Subject: Re: Improving Function.prototype.bind On Jan 5, 2012, at 4:47 PM, Andrea Giammarchi wrote: Guys, by any chance we can go back into the topic? You'll have to polyfill Function.prototype.bind in the current world of pre-ES5 browsers. Why not then go on to wrap it in a memoizing version that uses a WeakMap if available (emulated with strong keys/values array-based implementation if not)? If you need this machinery, it's all doable. If we should evolve a Harmony bind or betterBind based on your experience and others, we can do that. Right now the lack of memoization is not a burning issue, from what I hear. You've raised it, I think for the first time on es-discuss. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Improving Function.prototype.bind
My proposal could break existing code so it’s probably not worth a shot in ES6. Maybe in ES7, then. From: Brendan Eich Sent: Friday, January 06, 2012 12:52 AM To: François REMY Cc: Axel Rauschmayer ; Andrea Giammarchi ; es-discuss Subject: Re: Improving Function.prototype.bind What *exactly* would you do here? Making methods auto-bind on extraction, with memoization? Please be concrete and specific. It would be to do the same thing as the old IE behavior with host functions. var $ = document.getElementById; $(‘id’) // works as expected, on document $.call(anotherDocument, ‘id’); // works as expected, on anotherDocument setImmediate(myObj.asyncAction); // works as expected That means that a function reference returned by obj.func would have a “default” this to be used when there’s no this available. Implementation may use an internal [[boundFunctions]] property to make sure to return the same “boundFunction” instance each time when accessed on an object. Or another trick could be used as operator overloading to make it feel like that while it’s not true (but it would need to update native functions like addEventListener as well, which is not easy/efficient). Please note that the current behavior of using a “Reference” doesn’t need to be updated, it’s just that when the reference is flattened to a “Function” it should be flattened in a “Default-Bound Function” instead. For most of the code I see on the web, it would not make any difference. This would not change the behavior of the bind function which makes a function whose “this” is ALWAYS the boundObject (consider document.querySelector.bind(document).call(document.body.firstChild, body)) François___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Improving Function.prototype.bind
Le 06/01/2012 06:03, Mark S. Miller a écrit : Such a built in memoization, whether by boundTo or this enhancement to bind itself, creates a fatal ambient communications channel. // initSES initialization, freezing all built in primordials other than the true global // load Alice as a confined object graph // load Bob as a confined object graph. Alice and Bob should not be able to communicate // Covert channels mean we might not be able to prevent them from communicating bits // But we must certainly prevent capability leaks Alice says Object.boundTo(Object).foo = capabilityBobShouldntGet; or Object.bind(Object).foo = capabilityBobShouldntGet; Bob says var HAH = Object.boundTo(Object).foo; or var HAH = Object.bind(Object).foo; David's WeakMap approach elegantly avoid this problem, because Alice and Bob can only communicate if they already share access to this WeakMap, in which case they could already communicate anyway. Are you talking about https://gist.github.com/1567494 ? Because I think I have the same issue. I think I faithfully implemented what Andrea described. Everyone with access to Object.prototype.boundTo has (implicitely) access to the WeakMap, so the capability leak you describe remains in my example, I think. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [friam] Fwd: Hash Collision Denial of Service
For hash maps with string keys, people can concatenate the string keys with a random prefix. This fixes this attack, and also prevents the attacker from using annoying keys like __proto__, hasOwnProperty or toString. It doesn't fix things for JSON though, if you are reading untrusted (in the DOS sense) JSON. While V8 is fixing this DOS attack, I am not entirely happy about that because it sends a signal that it is a good idea to use non-prefixed property strings on objects as hash maps. The issues around that are often much worse than a CPU eating DOS that only really hurts when you have more than 10k keys. See for example https://groups.google.com/a/googleproductforums.com/forum/#!category-topic/docs/documents/0hQWeOvCcHU 2012/1/6 Mark S. Miller erig...@google.com: There is currently an informal (partial?) consensus to try to add high entropy identity hashes to ES6 (but no proposal page yet), so that users can build hashtables for themselves. Were they to do so, they immediately find they'd want to include non-objects as keys as well (like Map does), and so we might be tempted to expose a stable data hashing function to support such uses. The following surprised me, even though it was apparently well known (not by me ;)) since 2003. from https://groups.google.com/forum/#!topic/friam/jKRZrb5bQEA: Forwarded conversation Subject: [friam] Fwd: Hash Collision Denial of Service From: Bill Frantz fra...@pwpconsult.com Date: Thu, Jan 5, 2012 at 11:51 AM To: Design fr...@googlegroups.com From: @RISK: The Consensus Security Vulnerability Alert Week 1 2012 == Forwarded Message == Date: 1/5/12 19:37 From: consensussecurityvulnerabilityal...@sans.org (The SANS Institute) 12.2.5 CVE: Not Available Platform: Cross Platform Title: Java Hash Collision Denial of Service Description: Java is a programming language. The application is exposed to a denial of service issue due to an error during hashing form posts and updating a hash table. Specially crafted forms in HTTP POST requests can trigger hash collisions resulting in high CPU consumption. Java 7 and prior are affected. Ref: http://www.ocert.org/advisories/ocert-2011-003.html http://www.securityfocus.com/bid/51236/references __ 12.2.6 CVE: Not Available Platform: Cross Platform Title: Python Hash Collision Denial of Service Description: Python is a programming language available for multiple platforms. The application is exposed to a denial of service issue due to an error during hashing form posts and updating a hash table. Specially crafted forms in HTTP POST requests can trigger hash collisions resulting in high CPU consumption. All versions of Python are affected. Ref: http://www.securityfocus.com/bid/51239/references __ == End Forwarded Message == It seems to me, short of using secure hashes, any use of hashtables is subject to this attack if the attacker can control the data being hashed. Cheers - Bill --- Bill Frantz |We used to quip that password is the most common 408-356-8506 | password. Now it's 'password1.' Who said users haven't www.periwinkle.com | learned anything about security? -- Bruce Schneier -- You received this message because you are subscribed to the Google Groups friam group. To post to this group, send email to fr...@googlegroups.com. To unsubscribe from this group, send email to friam+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/friam?hl=en. -- From: Brian Warner war...@lothar.com Date: Thu, Jan 5, 2012 at 12:09 PM To: fr...@googlegroups.com Given the limited number of output buckets, I don't think a secure hash would win you much (i.e. there are no secure 10-bit hashes). Instead, I think you want to mix things up a bit, by including a per-runtime random secret in the hash calculation (generated each time the program starts, maybe for each dictionary you allocate). And then hope that you don't expose enough information to the attacker (perhaps by enumerating dictionaries in implementation-defined order without sorting the keys) to let them deduce the secret, and thus be able to force a lot of collisions. I was re-reading djb/agl's articles on crit-bit trees (aka PATRICIA trees, or tries, for those in the router world), and making the argument that programming languages should use a crit-bit tree as their fundamental data structure rather than a hash-table -based dictionary (because you get some additional operations for cheap, like sorted enumeration). I'm not sure if this would be any less vulnerable to attack.. seems like a series of [1,11,111,,1,..] keys would cause similar problems. http://cr.yp.to/critbit.html
Re: Improving Function.prototype.bind
that's pretty much what I have already written in my blog ... isn't it? The speed up is that ghost list of bound functions per object hard to properly manage, performances speaking, via pure JS It seems that at least you perfectly got what I am talking about, yeah :D br On Fri, Jan 6, 2012 at 10:29 AM, François REMY fremycompany_...@yahoo.frwrote: Such an implementation would be very slow and not efficient, because searching for a key in the boundFunctions weakmap would take time. It can be a polyfill solution but a new implementation need something better. I think the solution would be to create an invisible [[boundFunctions]] property for all objects containing a dictionnaryweakfunction, weakboundFunction of already-bound functions on the object. The implementation of bind would then be : - if objToBind is not a reference, create a new boundFunction and return it. - if objToBind.[[boundFunctions]] don't exist, create it. - else, check if it contains a key for functionToBind //when you are processing the dictionnary, remove obsolete entries you may find - if yes, check if the weak reference is alive - if yes, returns the boundFunction - create a new boundFunction and store it into objToBind.[[boundFunctions]] - return the newly created boundFunction Would that be possible? François -Message d'origine- From: Brendan Eich Sent: Friday, January 06, 2012 2:22 AM To: Andrea Giammarchi Cc: Axel Rauschmayer ; François REMY ; es-discuss Subject: Re: Improving Function.prototype.bind On Jan 5, 2012, at 4:47 PM, Andrea Giammarchi wrote: Guys, by any chance we can go back into the topic? You'll have to polyfill Function.prototype.bind in the current world of pre-ES5 browsers. Why not then go on to wrap it in a memoizing version that uses a WeakMap if available (emulated with strong keys/values array-based implementation if not)? If you need this machinery, it's all doable. If we should evolve a Harmony bind or betterBind based on your experience and others, we can do that. Right now the lack of memoization is not a burning issue, from what I hear. You've raised it, I think for the first time on es-discuss. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Improving Function.prototype.bind
Le 06/01/2012 10:40, Andrea Giammarchi a écrit : if WeakMaps are so smart ... it means we cannot shim them without causing leaks in non WeakMap ready browsers since no magic will happen,objects as keys will simply be persistent in the WeakMap private scope Indeed. Also, Mark Miller mentionned a couple of times that the SES polyfill [1] leaks less than one could expect. I haven't taken the time to look into that but it's probably worth mentionning. ...does not look good, means we cannot solve this via libraries, means my initial proposal is better, leaks speaking, and it uses same WeakMap concept ( which to me is not new at all, check my Relator function if you want, it's from years ago ) Your proposal won't be implemented in older browsers. Actually, it is very likely that your proposal would be implemented in browsers that would already have weak maps. Under these conditions. What is the benefit of a native implementation rather than an WeakMap based polyfill? David [1] http://code.google.com/p/es-lab/source/browse/trunk/src/ses/WeakMap.js br On Fri, Jan 6, 2012 at 10:27 AM, David Bruant bruan...@gmail.com mailto:bruan...@gmail.com wrote: Le 05/01/2012 23:10, Andrea Giammarchi a écrit : leaks When a function has no strong reference, the associated entry in the first WeakMap (which is the second level of weakmap) can be GC'ed. When an object has no strong reference, all entries in second-level WeakMaps can be collected. I don't see any leaks. Assuming a GC with reachability, each bound function is kept only if both the function and the object are still in the environment (which is the minimum we need to achieve the functional goal). performances A native implementation can use a hash table using the 2 references as keys. I don't know to what extent it would be that much better. as example, are the first things I have in mind when I look at that code ( assuming I understand how WeakMap works there ) (...) My point is that Function.prototype.bind is used 90% of the time with context only, 10% with arguments, 0% as different object since nobody uses two bound functions to the same object, arguments a part. And you obviously have a one-year study crawling over 100,000 websites and 1000 node projects to back these numbers? Also, does use refer to the occurence of code written doing what you describe or occurence of run? All in all, let's not use numbers or quantifiers when there is no backing besides the experience of a few, because no reliable decision can really be taken based on that. Function.prototype.bind could have been implemented via libraries ( as Prototype did ) as well so I don't get your argument, sorry. I am suggesting a semantic improvement Object related but of course I can solve all missing real-nedeed things via a library ... you know what I mean? My point is that what can be solved efficiently should be by a library. I think the solution I've provided would be satifactory (you can obviously disagree). I'm more interested in ECMAScript solving problems that either can't be solved or not efficiently. This currently includes private names, weakmaps, modules, proxies, all the syntax sugar, binary data... David Regards On Thu, Jan 5, 2012 at 11:01 PM, David Bruant bruan...@gmail.com mailto:bruan...@gmail.com wrote: Hi Andrea, It seems that what you want can be implemented as a library [1] (actually you did it as well in your blog post). In this gist, a cache is used. In a nutshell, it is a '(function, object) - boundFunction' mapping. I used 2 levels of WeakMaps to achieve this. I don't think a native implementation could be that much more efficient neither in space nor time. Assuming my implementation does what you need, what would be the benefit of a native implementation over what I propose? David [1] https://gist.github.com/1567494 Le 05/01/2012 14:54, Andrea Giammarchi a écrit : I have thought it may be interesting to receive some comment here too ... so here the short summary: genericCallback.bind(sameObject) !== genericCallback.bind(sameObject) quite inconvenient for listeners and leading to uncomfortable patterns ( store the bound reference somewhere and get it back later ) plus bind, at the end of a function, where the topic is the context, looks more like a yoda statement function with context as this object rather than object as context of this function So, the proposal, is a simplified Object.prototype.boundTo ( or eventually, to avoid conflicts with bind signature Object.prototype.asContextOf ) where the action is
Re: Improving Function.prototype.bind
On Fri, Jan 6, 2012 at 10:50 AM, David Bruant bruan...@gmail.com wrote: Your proposal won't be implemented in older browsers. Actually, it is very likely that your proposal would be implemented in browsers that would already have weak maps. Under these conditions. What is the benefit of a native implementation rather than an WeakMap based polyfill? David [1] http://code.google.com/p/es-lab/source/browse/trunk/src/ses/WeakMap.js Why would you say that ? This version https://gist.github.com/1569978should works in every browser without problems. I have also tested memory leaks via snapshots through the profiler ... // snapshot, 1.2 Mb function test(){} for (var i = 0, a = []; i 0x; i++) a.push({}.boundTo(test)); // snapshot 35.8 Mb a = null; // snapshot, 1.2 Mb Andno WeakMap is used ... am I missing something ? Cheers, Andrea ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Improving Function.prototype.bind
Le 06/01/2012 11:20, Andrea Giammarchi a écrit : On Fri, Jan 6, 2012 at 10:50 AM, David Bruant bruan...@gmail.com mailto:bruan...@gmail.com wrote: Your proposal won't be implemented in older browsers. Actually, it is very likely that your proposal would be implemented in browsers that would already have weak maps. Under these conditions. What is the benefit of a native implementation rather than an WeakMap based polyfill? David [1] http://code.google.com/p/es-lab/source/browse/trunk/src/ses/WeakMap.js Why would you say that ? This version https://gist.github.com/1569978 should works in every browser without problems. I meant that your proposal won't be implemented *natively* by older browsers. Sorry for the confusion. I have also tested memory leaks via snapshots through the profiler ... // snapshot, 1.2 Mb function test(){} for (var i = 0, a = []; i 0x; i++) a.push({}.boundTo(test)); // snapshot 35.8 Mb a = null; // snapshot, 1.2 Mb And no WeakMap is used ... am I missing something ? In your implementation, you store in an array references to functions, not to objects. I would guess that - var o = {}; for (var i = 0, a = []; i 0x; i++) a.push(o.boundTo(function(){})); a = null; - leaks. Does it? I certainly leaks, because references to the functions accumulate in 'cbStack' and are never free'd. Having an own boundTo property in every single object saves you from a memory leak in the snippet you wrote above... at the cost of potential collisions (and an abstraction leak). And it would be an enumerable property in an ES3 browser. I would prefer the extra memory leak in this case, but that's a matter of taste. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
Ok, is there any observable difference between what you would have future browsers do, vs the equivalent mechanisms except that program #2 is categorized as an ES6 program and processed as such? If there is no observable difference, good. Then it's only a matter of how we describe an agreed semantics. If there is an observable difference, how is this not three modes? There should be no observable difference. But the issue isn't how we described the (program) semantics. It is how we decide which semantics to apply. The tricky cases are thing like: function f(a) { arguments[0]=2; return a } print(f(1)); //2 if ES5, 1 if ES6 There is nothing in the source file that implies which specification to apply so for backwards computability a browser must default to interpreting such program as a ES5 program. Anything syntactically unique to ES5 (eg, use of a with statment) or ES6 (eg, use rest or spread) would force one interpretation or another But what you are saying is that ES6 is not a superset of ES5.strict, right? I thought that there were only 2 semantics: 1. ES5.non-strict (which is a superset of all previous versions) [a.k.a. non-strict] 2. ES6 (which is a superset of ES5.strict) [a.k.a. strict] My understanding is that #1 would be the default and when one encounters anything ES6-specific (an “ES6 trigger”) or use strict then the semantics switches to #2. = encountering a with statement would be fine, because #1 is the default, anyway. = encountering a with statement and either an ES6 trigger or a use strict would be an error. As a human, I would want an ES6 trigger to appear as early as possible. I wouldn’t want to read through a file, encounter an ES6 trigger at the end and then have to revise the understanding of the code that I had so far. I like the whole-file-or-nothing approach for switching semantics that you proposed. -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Improving Function.prototype.bind
it doesn't ... as soon as you release the reference to o no leaks persists but of course until you keep o on hold those unique callbacks cannot be released ... but this would be true with WeakMap too, isn't it? In any case, boundTo is suitable for listeners and the whole point is to do not hold manually those function once again window.addEventListener(whatever, o.boundTo(o.method), false); // later on window.removeEventListener(whatever, o.boundTo(o.method), false); // that's it We can reuse/add the listener later on without problems but as soon as object o will be unreachable (no reference count === 0) everything will be fine This, versus this anti pattern o._leMethodBound = o.method.bind(o); window.addEventListener(whatever, o._leMethodBound, false); // later on window.removeEventListener(whatever, o._leMethodBound, false); o._leMethodBound is exposed and used only to hold a bound method ... we have all done this until now, and to me it's kinda illogical, boring, error prone Regards, Andrea On Fri, Jan 6, 2012 at 11:41 AM, David Bruant bruan...@gmail.com wrote: In your implementation, you store in an array references to functions, not to objects. I would guess that - var o = {}; for (var i = 0, a = []; i 0x; i++) a.push(o.boundTo(function(){})); a = null; - leaks. Does it? I certainly leaks, because references to the functions accumulate in 'cbStack' and are never free'd. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Improving Function.prototype.bind
Le 06/01/2012 12:23, Andrea Giammarchi a écrit : it doesn't ... as soon as you release the reference to o no leaks persists but of course until you keep o on hold those unique callbacks cannot be released ... If you're telling me that keeping only one of the object or the function alive but not both keeps the bound function alive, then you do have a leak. The bound function only has a reason to exist if both the object and the function remain in the program. but this would be true with WeakMap too, isn't it? No it wouldn't. Since WeakMaps keep weak references, you can't have the type of leaks I just described. As I said in [1], the bound function will be kept in memory only if both the object and the function are still strongly held somewhere (so the weakmap doesn't count). In any case, boundTo is suitable for listeners and the whole point is to do not hold manually those function once again window.addEventListener(whatever, o.boundTo(o.method), false); // later on window.removeEventListener(whatever, o.boundTo(o.method), false); // that's it We can reuse/add the listener later on without problems but as soon as object o will be unreachable (no reference count === 0) Reference count === 0 and unreachable are different properties. An object can be unreachable even with a reference count different of 0. everything will be fine This, versus this anti pattern o._leMethodBound = o.method.bind(o); window.addEventListener(whatever, o._leMethodBound, false); // later on window.removeEventListener(whatever, o._leMethodBound, false); o._leMethodBound is exposed only because of your implementation. and used only to hold a bound method ... we have all done this until now, and to me it's kinda illogical, boring, error prone I fully agree with your use case. Yet, you still haven't answered my question: If browsers implemented your proposal, it would certainly be in new versions that will certainly already have WeakMaps built-in. In this case, what would be the benefit of a native implementation rather than a library of yours? Regarding your earlier argument about 'bind' being often implemented in libraries, it has to be noted that ES5 version of bind has features that ES3-based polyfill cannot emulate including being safe against redefinition of 'call' and 'apply'. David [1] https://mail.mozilla.org/pipermail/es-discuss/2012-January/019306.html ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Improving Function.prototype.bind
unreachable without reference count? do you have an example different from a private scope object that is reachable from that scope so I would not call it unreachable? In any case I understand your leaks point and if WeakMap solves this, but I strongly believe no shim will be able to emulate this behavior, no matters how much articulated the implementation is ( taking that google shim as example that also won't work as it is in older browsers in any case ) Then this is a dead line, something that you said makes sense as problem, won't be solved natively because it can be implemented via libraries ... but if this is the logic, I wonder what is ES5 about with all its extras ( Array, Function, String, etc ) Regards On Fri, Jan 6, 2012 at 12:42 PM, David Bruant bruan...@gmail.com wrote: Le 06/01/2012 12:23, Andrea Giammarchi a écrit : it doesn't ... as soon as you release the reference to o no leaks persists but of course until you keep o on hold those unique callbacks cannot be released ... If you're telling me that keeping only one of the object or the function alive but not both keeps the bound function alive, then you do have a leak. The bound function only has a reason to exist if both the object and the function remain in the program. but this would be true with WeakMap too, isn't it? No it wouldn't. Since WeakMaps keep weak references, you can't have the type of leaks I just described. As I said in [1], the bound function will be kept in memory only if both the object and the function are still strongly held somewhere (so the weakmap doesn't count). In any case, boundTo is suitable for listeners and the whole point is to do not hold manually those function once again window.addEventListener(whatever, o.boundTo(o.method), false); // later on window.removeEventListener(whatever, o.boundTo(o.method), false); // that's it We can reuse/add the listener later on without problems but as soon as object o will be unreachable (no reference count === 0) Reference count === 0 and unreachable are different properties. An object can be unreachable even with a reference count different of 0. everything will be fine This, versus this anti pattern o._leMethodBound = o.method.bind(o); window.addEventListener(whatever, o._leMethodBound, false); // later on window.removeEventListener(whatever, o._leMethodBound, false); o._leMethodBound is exposed only because of your implementation. and used only to hold a bound method ... we have all done this until now, and to me it's kinda illogical, boring, error prone I fully agree with your use case. Yet, you still haven't answered my question: If browsers implemented your proposal, it would certainly be in new versions that will certainly already have WeakMaps built-in. In this case, what would be the benefit of a native implementation rather than a library of yours? Regarding your earlier argument about 'bind' being often implemented in libraries, it has to be noted that ES5 version of bind has features that ES3-based polyfill cannot emulate including being safe against redefinition of 'call' and 'apply'. David [1] https://mail.mozilla.org/pipermail/es-discuss/2012-January/019306.html ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
-Pôvodná správa- From: Axel Rauschmayer Sent: Friday, January 06, 2012 12:11 PM To: Allen Wirfs-Brock Cc: Mark S. Miller ; Brendan Eich ; es-discuss Steen Subject: Re: ES6 doesn't need opt-in ... As a human, I would want an ES6 trigger to appear as early as possible. I wouldn’t want to read through a file, encounter an ES6 trigger at the end and then have to revise the understanding of the code that I had so far. I like the whole-file-or-nothing approach for switching semantics that you proposed. -- Dr. Axel Rauschmayer a...@rauschma.de === But you can! Allen has explicitly said put 'let ES6;' at the beginning if you want to force ES6. As a human, you can argue that it is humanly to actually do it. And when the code is such that it is really ES5ES6 the whole time and only at the end the ES6 feature is used, then what? It is so. I think the Mark Miller's has the huge benefit that the ES6 spec can avoid describing the semantics of non-strict code. Cool. is undepinning what the real value behind the Allen's state machine is. Herby ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Improving Function.prototype.bind
Le 06/01/2012 12:51, Andrea Giammarchi a écrit : unreachable without reference count? do you have an example different from a private scope object that is reachable from that scope so I would not call it unreachable? I'm not sure I understand your question. In IE6 (7? 8?), written naively, event handlers often had a reference to the element they were bound to (via scope chain) and the element had a reference to the handler (obviously). It created a cycle that reference counting based GC was unable to collect. Mark-and-sweep GCs don't have this problem at all. It doesn't prevent every memory leak (no GC can), but is far more efficient in obvious cases than reference counting. In any case I understand your leaks point and if WeakMap solves this, but I strongly believe no shim will be able to emulate this behavior, no matters how much articulated the implementation is ( taking that google shim as example that also won't work as it is in older browsers in any case ) Yes, in older browser, any implementation of what you want would leak in some cases. Then this is a dead line, something that you said makes sense as problem, won't be solved natively because it can be implemented via libraries ... but if this is the logic, I wonder what is ES5 about with all its extras ( Array, Function, String, etc ) I would guess uniformisation of very frequent patterns (forEach, map, filter...), a need for a reliable isArray method that some libraries got right and other completely wrong. ES5 was far more that these shimable extras: strict mode, fine grained property control, getters/setters to name a few. There was probably also some evangelisation or politics. Take Object.create. Besides the second argument, it can be shimed. Yes, but having this fundamental construct also helps a lot in understanding and teaching the language. Also, I did not say that everything that can be done with a library should not be part of the language. I'm in priority interested in seeing in the language things that cannot be done (at all or efficiently) with a library. That's just a priority (of mine, by the way. I haven't seen an expression of TC39, but the current list of proposal speaks for itself, I think) It seems that it has been in JavaScript from the beginning that the language provides basic bricks and people can feel free to create themselves what they want/need on top of that. Some patterns were very common and have later been integrated into the language. Some functions could probably be made far more efficient or reliable when integrated in the language. I think that bringing in the language things that can be implemented in libraries should be justified by more than a use case. For instance, I'm enthusiastic of promises [1], these are more and more used, there are a lot of different APIs. It will be interesting to see what wins and bring this to ECMAScript when it seems promises have been explored. But I still don't see a strong justification in a memoized bind. I understand and agree with the use case, but it doesn't seem enough to bring it into the core language (and you haven't answered the security concern raised by Mark...) David [1] http://wiki.ecmascript.org/doku.php?id=strawman:concurrency ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Improving Function.prototype.bind
there is no security issue ... it's meant like that plus what Mark did not think about, is that if I use (function () { function callback() {} var object = {}; window.addEventListener(no way, object.boundTo(callback), false); // later on window.removeEventListener(no way, object.boundTo(callback), false); }()); inside a scope other objects can not reach, nobody will ever be able to retrieve the resulting bound function/object. The security issue is indeed all over *now* with current way to store bound once callbacks per object. object._boundMethod = object.method.bind(object); Above pattern is able to destroy entire framework but nobody ever complained ... well, glad to be the first one. br On Fri, Jan 6, 2012 at 4:23 PM, David Bruant bruan...@gmail.com wrote: Le 06/01/2012 12:51, Andrea Giammarchi a écrit : unreachable without reference count? do you have an example different from a private scope object that is reachable from that scope so I would not call it unreachable? I'm not sure I understand your question. In IE6 (7? 8?), written naively, event handlers often had a reference to the element they were bound to (via scope chain) and the element had a reference to the handler (obviously). It created a cycle that reference counting based GC was unable to collect. Mark-and-sweep GCs don't have this problem at all. It doesn't prevent every memory leak (no GC can), but is far more efficient in obvious cases than reference counting. In any case I understand your leaks point and if WeakMap solves this, but I strongly believe no shim will be able to emulate this behavior, no matters how much articulated the implementation is ( taking that google shim as example that also won't work as it is in older browsers in any case ) Yes, in older browser, any implementation of what you want would leak in some cases. Then this is a dead line, something that you said makes sense as problem, won't be solved natively because it can be implemented via libraries ... but if this is the logic, I wonder what is ES5 about with all its extras ( Array, Function, String, etc ) I would guess uniformisation of very frequent patterns (forEach, map, filter...), a need for a reliable isArray method that some libraries got right and other completely wrong. ES5 was far more that these shimable extras: strict mode, fine grained property control, getters/setters to name a few. There was probably also some evangelisation or politics. Take Object.create. Besides the second argument, it can be shimed. Yes, but having this fundamental construct also helps a lot in understanding and teaching the language. Also, I did not say that everything that can be done with a library should not be part of the language. I'm in priority interested in seeing in the language things that cannot be done (at all or efficiently) with a library. That's just a priority (of mine, by the way. I haven't seen an expression of TC39, but the current list of proposal speaks for itself, I think) It seems that it has been in JavaScript from the beginning that the language provides basic bricks and people can feel free to create themselves what they want/need on top of that. Some patterns were very common and have later been integrated into the language. Some functions could probably be made far more efficient or reliable when integrated in the language. I think that bringing in the language things that can be implemented in libraries should be justified by more than a use case. For instance, I'm enthusiastic of promises [1], these are more and more used, there are a lot of different APIs. It will be interesting to see what wins and bring this to ECMAScript when it seems promises have been explored. But I still don't see a strong justification in a memoized bind. I understand and agree with the use case, but it doesn't seem enough to bring it into the core language (and you haven't answered the security concern raised by Mark...) David [1] http://wiki.ecmascript.org/**doku.php?id=strawman:**concurrencyhttp://wiki.ecmascript.org/doku.php?id=strawman:concurrency ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
No sorry, I just spotted the flaw. The observable difference is that a conforming browser is not required by the (ES5 + ES6) specs to provide any non-triggering ES6 features for program #2. In that case, we again have three mode. For example, since legacy constrains us from making nested named function declarations a triggering feature, if program #2 has a nested named function and the browser rejected it, that browser would still conform to both the ES5 and ES6 spec. The easy fix is to make use strict; a triggering condition. For non-strict code, by the state machine, the ES6 spec would still delegate to the ES5 spec. And the ES6 spec would otherwise be the same. But the strict portion of the ES5 spec would simply be dead code, because all of the conditions that would trigger it have already triggered the state machine into using the ES5 spec. On Fri, Jan 6, 2012 at 12:30 AM, Mark S. Miller erig...@google.com wrote: On Fri, Jan 6, 2012 at 12:24 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: There should be no observable difference. But the issue isn't how we described the (program) semantics. It is how we decide which semantics to apply. Got it. It still gives the web only two modes, but has the huge benefit that the ES6 spec can avoid describing the semantics of non-strict code. Cool. -- Cheers, --MarkM -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Improving Function.prototype.bind
Le 06/01/2012 16:54, Andrea Giammarchi a écrit : there is no security issue ... it's meant like that plus what Mark did not think about, is that if I use (function () { function callback() {} var object = {}; window.addEventListener(no way, object.boundTo(callback), false); // later on window.removeEventListener(no way, object.boundTo(callback), false); }()); inside a scope other objects can not reach, nobody will ever be able to retrieve the resulting bound function/object. Of course, the case you show is not a problem. The problem arise when 2 potentially malicious scripts have access to the same object (Mark used 'Object' as an example). But with modules, module loaders and the end of global scope, I wonder to what extent this happens. i'll answer directly to Mark message to discuss this. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [friam] Fwd: Hash Collision Denial of Service
Yes, that example is indeed much worse than this dos attack. But the fix does not need random prefixes, and indeed random prefixes are way overkill. http://code.google.com/p/es-lab/source/browse/trunk/src/ses/StringMap.jssolves this problem by simply using $ as a suffix on a fresh object that inherits from nothing. On Fri, Jan 6, 2012 at 1:40 AM, Erik Corry erik.co...@gmail.com wrote: For hash maps with string keys, people can concatenate the string keys with a random prefix. This fixes this attack, and also prevents the attacker from using annoying keys like __proto__, hasOwnProperty or toString. It doesn't fix things for JSON though, if you are reading untrusted (in the DOS sense) JSON. While V8 is fixing this DOS attack, I am not entirely happy about that because it sends a signal that it is a good idea to use non-prefixed property strings on objects as hash maps. The issues around that are often much worse than a CPU eating DOS that only really hurts when you have more than 10k keys. See for example https://groups.google.com/a/googleproductforums.com/forum/#!category-topic/docs/documents/0hQWeOvCcHU 2012/1/6 Mark S. Miller erig...@google.com: There is currently an informal (partial?) consensus to try to add high entropy identity hashes to ES6 (but no proposal page yet), so that users can build hashtables for themselves. Were they to do so, they immediately find they'd want to include non-objects as keys as well (like Map does), and so we might be tempted to expose a stable data hashing function to support such uses. The following surprised me, even though it was apparently well known (not by me ;)) since 2003. from https://groups.google.com/forum/#!topic/friam/jKRZrb5bQEA: Forwarded conversation Subject: [friam] Fwd: Hash Collision Denial of Service From: Bill Frantz fra...@pwpconsult.com Date: Thu, Jan 5, 2012 at 11:51 AM To: Design fr...@googlegroups.com From: @RISK: The Consensus Security Vulnerability Alert Week 1 2012 == Forwarded Message == Date: 1/5/12 19:37 From: consensussecurityvulnerabilityal...@sans.org (The SANS Institute) 12.2.5 CVE: Not Available Platform: Cross Platform Title: Java Hash Collision Denial of Service Description: Java is a programming language. The application is exposed to a denial of service issue due to an error during hashing form posts and updating a hash table. Specially crafted forms in HTTP POST requests can trigger hash collisions resulting in high CPU consumption. Java 7 and prior are affected. Ref: http://www.ocert.org/advisories/ocert-2011-003.html http://www.securityfocus.com/bid/51236/references __ 12.2.6 CVE: Not Available Platform: Cross Platform Title: Python Hash Collision Denial of Service Description: Python is a programming language available for multiple platforms. The application is exposed to a denial of service issue due to an error during hashing form posts and updating a hash table. Specially crafted forms in HTTP POST requests can trigger hash collisions resulting in high CPU consumption. All versions of Python are affected. Ref: http://www.securityfocus.com/bid/51239/references __ == End Forwarded Message == It seems to me, short of using secure hashes, any use of hashtables is subject to this attack if the attacker can control the data being hashed. Cheers - Bill --- Bill Frantz|We used to quip that password is the most common 408-356-8506 | password. Now it's 'password1.' Who said users haven't www.periwinkle.com | learned anything about security? -- Bruce Schneier -- You received this message because you are subscribed to the Google Groups friam group. To post to this group, send email to fr...@googlegroups.com. To unsubscribe from this group, send email to friam+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/friam?hl=en. -- From: Brian Warner war...@lothar.com Date: Thu, Jan 5, 2012 at 12:09 PM To: fr...@googlegroups.com Given the limited number of output buckets, I don't think a secure hash would win you much (i.e. there are no secure 10-bit hashes). Instead, I think you want to mix things up a bit, by including a per-runtime random secret in the hash calculation (generated each time the program starts, maybe for each dictionary you allocate). And then hope that you don't expose enough information to the attacker (perhaps by enumerating dictionaries in implementation-defined order without sorting the keys) to let them deduce the secret, and thus be able to force a lot of collisions. I was re-reading djb/agl's articles on
Re: Improving Function.prototype.bind
On Fri, Jan 6, 2012 at 8:31 AM, David Bruant bruan...@gmail.com wrote: Le 06/01/2012 06:03, Mark S. Miller a écrit : Such a built in memoization, whether by boundTo or this enhancement to bind itself, creates a fatal ambient communications channel. // initSES initialization, freezing all built in primordials other than the true global // load Alice as a confined object graph // load Bob as a confined object graph. Alice and Bob should not be able to communicate // Covert channels mean we might not be able to prevent them from communicating bits // But we must certainly prevent capability leaks Alice says Object.boundTo(Object).foo = capabilityBobShouldntGet; Bob says var HAH = Object.boundTo(Object).foo; If Alice and Bob have been loaded as confined object graphs, they could both be exposed different objects for what each refer to as Object, no? It depends on the intentions of the party that instantiated the confined Alice and Bob -- call her Carol the Confiner, or simply Carol. If Carol wants to have a rich interaction with Alice and Bob, then she will typically want Alice, Bob, and Carol to all exist within a single SES context (frame) and thereby share the same Object. That way, none of them have to worry about the weird and complex behavior of, for example, instanceof, when computing across multiple frames. Very concretely, Carol will want to have the same Object as Alice, and to have the same Object as Bob. Therefore, Alice and Bob will have the same Object as each other. Sharing Object and the other accessible built-in primordials (i.e., all the primordials except the global object) is safe in SES because the accessible primordial state contains no communications channels. To a first approximation, it contains no mutable state at all. The only exceptions are Date.now(), Date(), and Math.random(), none of which creates a communications channel. [...] Ps: by the way, what does HAH mean? It is Bob's evil laugh, as Alice and Bob have successfully conspired to leak capabilityBobShouldntGet to Bob. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Improving Function.prototype.bind
Alice wouldn't normally be able to communicate 'bound' to Bob, and thus Bob wouldn't be able to read Alice's 'bound.foo'. The issue is much like ES3's mistake of evaluation a RegExp literal once to a RegExp object -- everyone executing the same code could now communicate, even if all accessible primordial state were frozen. The answer to both is the same -- the immutable objects they share can only return mutable objects if these objects are fresh. Alice and Bob can then separately mutate them without being able to observe each other's mutations. This is why it is essential that .bind() return a fresh object each time it is called. On Fri, Jan 6, 2012 at 12:58 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: same thing this does var bound = Object.bind(Object); bound.foo = capabilityBobShouldntGet; // who does this ? var HAH = bound.foo; ... so I am missing your point I guess ... but my proposal wants to return always same object for 99.9% of usage out there ... On Fri, Jan 6, 2012 at 8:55 AM, Mark S. Miller erig...@google.com wrote: In your proposal, what does this code sequence do: Object.boundTo(Object).foo = capabilityBobShouldntGet; var HAH = Object.boundTo(Object).foo; ? -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Improving Function.prototype.bind
On Fri, Jan 6, 2012 at 1:29 AM, François REMY fremycompany_...@yahoo.frwrote: Such an implementation would be very slow and not efficient, because searching for a key in the boundFunctions weakmap would take time. It can be a polyfill solution but a new implementation need something better. I think the solution would be to create an invisible [[boundFunctions]] property for all objects containing a dictionnaryweakfunction, weakboundFunction of already-bound functions on the object. The implementation of bind would then be : - if objToBind is not a reference, create a new boundFunction and return it. - if objToBind.[[boundFunctions]] don't exist, create it. - else, check if it contains a key for functionToBind //when you are processing the dictionnary, remove obsolete entries you may find - if yes, check if the weak reference is alive - if yes, returns the boundFunction - create a new boundFunction and store it into objToBind.[[boundFunctions]] - return the newly created boundFunction Would that be possible? No, for the same reason. The mutable state you hung off this internal property creates an ambient communications channel. François -Message d'origine- From: Brendan Eich Sent: Friday, January 06, 2012 2:22 AM To: Andrea Giammarchi Cc: Axel Rauschmayer ; François REMY ; es-discuss Subject: Re: Improving Function.prototype.bind On Jan 5, 2012, at 4:47 PM, Andrea Giammarchi wrote: Guys, by any chance we can go back into the topic? You'll have to polyfill Function.prototype.bind in the current world of pre-ES5 browsers. Why not then go on to wrap it in a memoizing version that uses a WeakMap if available (emulated with strong keys/values array-based implementation if not)? If you need this machinery, it's all doable. If we should evolve a Harmony bind or betterBind based on your experience and others, we can do that. Right now the lack of memoization is not a burning issue, from what I hear. You've raised it, I think for the first time on es-discuss. /be __**_ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Improving Function.prototype.bind
Le 06/01/2012 17:43, Mark S. Miller a écrit : On Fri, Jan 6, 2012 at 8:31 AM, David Bruant bruan...@gmail.com mailto:bruan...@gmail.com wrote: Le 06/01/2012 06:03, Mark S. Miller a écrit : Such a built in memoization, whether by boundTo or this enhancement to bind itself, creates a fatal ambient communications channel. // initSES initialization, freezing all built in primordials other than the true global // load Alice as a confined object graph // load Bob as a confined object graph. Alice and Bob should not be able to communicate // Covert channels mean we might not be able to prevent them from communicating bits // But we must certainly prevent capability leaks Alice says Object.boundTo(Object).foo = capabilityBobShouldntGet; Bob says var HAH = Object.boundTo(Object).foo; If Alice and Bob have been loaded as confined object graphs, they could both be exposed different objects for what each refer to as Object, no? It depends on the intentions of the party that instantiated the confined Alice and Bob -- call her Carol the Confiner, or simply Carol. If Carol wants to have a rich interaction with Alice and Bob, then she will typically want Alice, Bob, and Carol to all exist within a single SES context (frame) and thereby share the same Object. That way, none of them have to worry about the weird and complex behavior of, for example, instanceof, when computing across multiple frames. Ok. I forgot that some mecanisms relied on object identity. Very concretely, Carol will want to have the same Object as Alice, and to have the same Object as Bob. Therefore, Alice and Bob will have the same Object as each other. Sharing Object and the other accessible built-in primordials (i.e., all the primordials except the global object) is safe in SES because the accessible primordial state contains no communications channels. To a first approximation, it contains no mutable state at all. The only exceptions are Date.now(), Date(), and Math.random(), none of which creates a communications channel. Indeed. Mutable state does not seem to be the issue by itself. The issue would be a mutable state that can be mutated by a script (which isn't the case for Date and random) [...] Ps: by the way, what does HAH mean? It is Bob's evil laugh, as Alice and Bob have successfully conspired to leak capabilityBobShouldntGet to Bob. :-) David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Improving Function.prototype.bind
On Fri, Jan 6, 2012 at 1:31 AM, David Bruant bruan...@gmail.com wrote: [...] David's WeakMap approach elegantly avoid this problem, because Alice and Bob can only communicate if they already share access to this WeakMap, in which case they could already communicate anyway. Are you talking about https://gist.github.com/**1567494https://gist.github.com/1567494? Because I think I have the same issue. I think I faithfully implemented what Andrea described. Everyone with access to Object.prototype.boundTo has (implicitely) access to the WeakMap, so the capability leak you describe remains in my example, I think. No, because that code would safely fail under SES, at the assignment Object.prototype.boundTo = function(fct){ since Object.prototype is frozen. I was referring to your approach. Note that I did not need to offer a specific alternative implementation and API, because any implementation and API that you design that actually provides this service under SES will require the memo state used to be separately instantiated for Alice and Bob. Thus Alice's memo cannot return something that Bob's memo memoized. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Improving Function.prototype.bind
Sorry, I don’t understand how. [[boundFunctions]] is not readable from the script itself, only from the UA. To retreive an element from [[boundFunctions]] you need the original function used to create it. If you’ve recieved an instance to that function, you already have a communication channel, right? Or am I missing something? From: Mark S. Miller Sent: Friday, January 06, 2012 5:53 PM To: François REMY Cc: Brendan Eich ; Andrea Giammarchi ; es-discuss Subject: Re: Improving Function.prototype.bind On Fri, Jan 6, 2012 at 1:29 AM, François REMY fremycompany_...@yahoo.fr wrote: Such an implementation would be very slow and not efficient, because searching for a key in the boundFunctions weakmap would take time. It can be a polyfill solution but a new implementation need something better. I think the solution would be to create an invisible [[boundFunctions]] property for all objects containing a dictionnaryweakfunction, weakboundFunction of already-bound functions on the object. The implementation of bind would then be : - if objToBind is not a reference, create a new boundFunction and return it. - if objToBind.[[boundFunctions]] don't exist, create it. - else, check if it contains a key for functionToBind //when you are processing the dictionnary, remove obsolete entries you may find - if yes, check if the weak reference is alive - if yes, returns the boundFunction - create a new boundFunction and store it into objToBind.[[boundFunctions]] - return the newly created boundFunction Would that be possible? No, for the same reason. The mutable state you hung off this internal property creates an ambient communications channel. François -Message d'origine- From: Brendan Eich Sent: Friday, January 06, 2012 2:22 AM To: Andrea Giammarchi Cc: Axel Rauschmayer ; François REMY ; es-discuss Subject: Re: Improving Function.prototype.bind On Jan 5, 2012, at 4:47 PM, Andrea Giammarchi wrote: Guys, by any chance we can go back into the topic? You'll have to polyfill Function.prototype.bind in the current world of pre-ES5 browsers. Why not then go on to wrap it in a memoizing version that uses a WeakMap if available (emulated with strong keys/values array-based implementation if not)? If you need this machinery, it's all doable. If we should evolve a Harmony bind or betterBind based on your experience and others, we can do that. Right now the lack of memoization is not a burning issue, from what I hear. You've raised it, I think for the first time on es-discuss. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Improving Function.prototype.bind
Yes. Under SES, Object is shared by Alice and Bob (and Carol). But it is not a communications channel since it (and all its methods, etc) are all frozen. On Fri, Jan 6, 2012 at 9:02 AM, François REMY fremycompany_...@yahoo.frwrote: Sorry, I don’t understand how. [[boundFunctions]] is not readable from the script itself, only from the UA. To retreive an element from [[boundFunctions]] you need the original function used to create it. If you’ve recieved an instance to that function, you already have a communication channel, right? Or am I missing something? *From:* Mark S. Miller erig...@google.com *Sent:* Friday, January 06, 2012 5:53 PM *To:* François REMY fremycompany_...@yahoo.fr *Cc:* Brendan Eich bren...@mozilla.com ; Andrea Giammarchiandrea.giammar...@gmail.com; es-discuss es-discuss@mozilla.org *Subject:* Re: Improving Function.prototype.bind On Fri, Jan 6, 2012 at 1:29 AM, François REMY fremycompany_...@yahoo.frwrote: Such an implementation would be very slow and not efficient, because searching for a key in the boundFunctions weakmap would take time. It can be a polyfill solution but a new implementation need something better. I think the solution would be to create an invisible [[boundFunctions]] property for all objects containing a dictionnaryweakfunction, weakboundFunction of already-bound functions on the object. The implementation of bind would then be : - if objToBind is not a reference, create a new boundFunction and return it. - if objToBind.[[boundFunctions]] don't exist, create it. - else, check if it contains a key for functionToBind //when you are processing the dictionnary, remove obsolete entries you may find - if yes, check if the weak reference is alive - if yes, returns the boundFunction - create a new boundFunction and store it into objToBind.[[boundFunctions]] - return the newly created boundFunction Would that be possible? No, for the same reason. The mutable state you hung off this internal property creates an ambient communications channel. François -Message d'origine- From: Brendan Eich Sent: Friday, January 06, 2012 2:22 AM To: Andrea Giammarchi Cc: Axel Rauschmayer ; François REMY ; es-discuss Subject: Re: Improving Function.prototype.bind On Jan 5, 2012, at 4:47 PM, Andrea Giammarchi wrote: Guys, by any chance we can go back into the topic? You'll have to polyfill Function.prototype.bind in the current world of pre-ES5 browsers. Why not then go on to wrap it in a memoizing version that uses a WeakMap if available (emulated with strong keys/values array-based implementation if not)? If you need this machinery, it's all doable. If we should evolve a Harmony bind or betterBind based on your experience and others, we can do that. Right now the lack of memoization is not a burning issue, from what I hear. You've raised it, I think for the first time on es-discuss. /be __**_ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Improving Function.prototype.bind
that whole variable can be redefined or used as communication channel ... I really don't understand what is the problem. The returned bound once object could be frozen without problems but if the function is private with the gist I have posted: 1. you cannot redefine Object.prototype at all 2. you cannot access single bound function/object from any other place If I have my own scope I want to do what's needed, this does not mean the problem does not exist, isn't it? In your case you have, as example, different problems with that WeakMap 1. everyone can WeakMap = function () {}; anywhere 2. if already defined, the definition of Object getOwnPropertyDescriptor to avoid access to that protected variable will fail and throw an error ... isn't it? That does not look safe either 3. as you wrote, Proxy easily discover that secret 4. your implementation has same problem I am talking about ... trapped protected/private stuff others should not see Same stuff with my problem except even proxy won't be able to retrieve that bound function since no property is attached. I can't hardly believe you are so worried about an edge case and you don't see the pachyderm we are all dealing with ... properties attached and accessible from everyone ... this is for you safe? Is obj.bound = obj.method.bind(obj) a better approach than the one I am suggesting ? I am sorry but I don't think so. Best Regards On Fri, Jan 6, 2012 at 6:03 PM, Mark S. Miller erig...@google.com wrote: On Fri, Jan 6, 2012 at 1:50 AM, David Bruant bruan...@gmail.com wrote: Le 06/01/2012 10:40, Andrea Giammarchi a écrit : if WeakMaps are so smart ... it means we cannot shim them without causing leaks in non WeakMap ready browsers since no magic will happen,objects as keys will simply be persistent in the WeakMap private scope Indeed. Also, Mark Miller mentionned a couple of times that the SES polyfill [1] leaks less than one could expect. I haven't taken the time to look into that but it's probably worth mentionning. And it's probably worth looking into ;) [1] http://code.google.com/p/es-lab/source/browse/trunk/src/ses/WeakMap.js -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 6, 2012, at 8:03 AM, Mark S. Miller wrote: No sorry, I just spotted the flaw. The observable difference is that a conforming browser is not required by the (ES5 + ES6) specs to provide any non-triggering ES6 features for program #2. In that case, we again have three mode. For example, since legacy constrains us from making nested named function declarations a triggering feature, if program #2 has a nested named function and the browser rejected it, that browser would still conform to both the ES5 and ES6 spec. Implementations that currently support extensions to ES5 (and wish to continue to support them) must classify their extensions into one of the four categories I identified and then process them according to the state machine. Because no currently implementation of function declarations within blocks (that I'm aware of) matches the ES6 lexical scoping semantics, it would expect such function declarations to be classified as ES5~ES6. Then, according to the state machine, a program like: function f(g) { //not the following will produce inconsistent results among common browsers if (!g) { function g() {return 1} } else if (typeof g !== 'function') { function g() {return 2} } return g; } will be processed using the (implementation extended) ES5 specification and both f and g would presumably be non-strict functions. If you wanted the above to be processed as ES6 code you would need to add some ES6-only features such as: let ES6; or use some other forced opt-in such as a version in the MIME type. The above is exactly analogies to how any standard ES5~ES6 features would be treated. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Improving Function.prototype.bind
On Fri, Jan 6, 2012 at 9:27 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: that whole variable can be redefined or used as communication channel ... I really don't understand what is the problem. The variable Object? No, in SES that's unassignable. As layered on ES5, we enforce that simply by making globalObject.Object a non-writable non-configurable data property. The returned bound once object could be frozen without problems but if the function is private with the gist I have posted: Essentially yes. The returned bound object would have to be transitively immutable, but in this case freeze may be enough. Of course, this can't be a fix to bind since that would break bind's current behavior. But if it were a new API as you suggest, that would no longer violate any principles, I believe. Separately, I do not believe the need for this is adequate to justify adding a new API. But that's a completely different topic. 1. you cannot redefine Object.prototype at all 2. you cannot access single bound function/object from any other place If I have my own scope I want to do what's needed, this does not mean the problem does not exist, isn't it? In your case you have, as example, different problems with that WeakMap 1. everyone can WeakMap = function () {}; anywhere Again, no they can't because all whitelisted global variables are unassignable. 2. if already defined, the definition of Object getOwnPropertyDescriptor to avoid access to that protected variable will fail and throw an error ... isn't it? That does not look safe either 3. as you wrote, Proxy easily discover that secret 4. your implementation has same problem I am talking about ... trapped protected/private stuff others should not see Same stuff with my problem except even proxy won't be able to retrieve that bound function since no property is attached. I can't hardly believe you are so worried about an edge case and you don't see the pachyderm we are all dealing with ... properties attached and accessible from everyone ... this is for you safe? Is obj.bound = obj.method.bind(obj) a better approach than the one I am suggesting ? I am sorry but I don't think so. I don't think the benefits you explain are worth the cost of a new API. But that's separate from the security issue. Best Regards On Fri, Jan 6, 2012 at 6:03 PM, Mark S. Miller erig...@google.com wrote: On Fri, Jan 6, 2012 at 1:50 AM, David Bruant bruan...@gmail.com wrote: Le 06/01/2012 10:40, Andrea Giammarchi a écrit : if WeakMaps are so smart ... it means we cannot shim them without causing leaks in non WeakMap ready browsers since no magic will happen,objects as keys will simply be persistent in the WeakMap private scope Indeed. Also, Mark Miller mentionned a couple of times that the SES polyfill [1] leaks less than one could expect. I haven't taken the time to look into that but it's probably worth mentionning. And it's probably worth looking into ;) [1] http://code.google.com/p/es-lab/source/browse/trunk/src/ses/WeakMap.js -- Cheers, --MarkM -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Improving Function.prototype.bind
On Fri, Jan 6, 2012 at 6:56 PM, Mark S. Miller erig...@google.com wrote: On Fri, Jan 6, 2012 at 9:27 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: that whole variable can be redefined or used as communication channel ... I really don't understand what is the problem. The variable Object? No, in SES that's unassignable. As layered on ES5, we enforce that simply by making globalObject.Object a non-writable non-configurable data property. I was rather talking about your WeakMap The returned bound once object could be frozen without problems but if the function is private with the gist I have posted: Essentially yes. The returned bound object would have to be transitively immutable, but in this case freeze may be enough. Of course, this can't be a fix to bind since that would break bind's current behavior. But if it were a new API as you suggest, that would no longer violate any principles, I believe. new API and frozen would just work for me Separately, I do not believe the need for this is adequate to justify adding a new API. But that's a completely different topic. 1. you cannot redefine Object.prototype at all 2. you cannot access single bound function/object from any other place If I have my own scope I want to do what's needed, this does not mean the problem does not exist, isn't it? In your case you have, as example, different problems with that WeakMap 1. everyone can WeakMap = function () {}; anywhere Again, no they can't because all whitelisted global variables are unassignable. it's a var WeakMap in the global scope ... still talking about your shim, probably I am missing some dependency? 2. if already defined, the definition of Object getOwnPropertyDescriptor to avoid access to that protected variable will fail and throw an error ... isn't it? That does not look safe either 3. as you wrote, Proxy easily discover that secret 4. your implementation has same problem I am talking about ... trapped protected/private stuff others should not see Same stuff with my problem except even proxy won't be able to retrieve that bound function since no property is attached. I can't hardly believe you are so worried about an edge case and you don't see the pachyderm we are all dealing with ... properties attached and accessible from everyone ... this is for you safe? Is obj.bound = obj.method.bind(obj) a better approach than the one I am suggesting ? I am sorry but I don't think so. I don't think the benefits you explain are worth the cost of a new API. But that's separate from the security issue. Fair enough, so dead line it is. br, andrea Best Regards On Fri, Jan 6, 2012 at 6:03 PM, Mark S. Miller erig...@google.comwrote: On Fri, Jan 6, 2012 at 1:50 AM, David Bruant bruan...@gmail.com wrote: Le 06/01/2012 10:40, Andrea Giammarchi a écrit : if WeakMaps are so smart ... it means we cannot shim them without causing leaks in non WeakMap ready browsers since no magic will happen,objects as keys will simply be persistent in the WeakMap private scope Indeed. Also, Mark Miller mentionned a couple of times that the SES polyfill [1] leaks less than one could expect. I haven't taken the time to look into that but it's probably worth mentionning. And it's probably worth looking into ;) [1] http://code.google.com/p/es-lab/source/browse/trunk/src/ses/WeakMap.js -- Cheers, --MarkM -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Improving Function.prototype.bind
Maybe interesting for others too, since we talked about WeakMap a lot in this thread: My essential polyfill here: https://gist.github.com/1571878 100% code coverage here: https://gist.github.com/1571887 Best Regards, Andrea Giammarchi ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
AFAICT, this agrees with my analysis of what your proposal means. How does this not result in three modes? On Fri, Jan 6, 2012 at 9:45 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On Jan 6, 2012, at 8:03 AM, Mark S. Miller wrote: No sorry, I just spotted the flaw. The observable difference is that a conforming browser is not required by the (ES5 + ES6) specs to provide any non-triggering ES6 features for program #2. In that case, we again have three mode. For example, since legacy constrains us from making nested named function declarations a triggering feature, if program #2 has a nested named function and the browser rejected it, that browser would still conform to both the ES5 and ES6 spec. Implementations that currently support extensions to ES5 (and wish to continue to support them) must classify their extensions into one of the four categories I identified and then process them according to the state machine. Because no currently implementation of function declarations within blocks (that I'm aware of) matches the ES6 lexical scoping semantics, it would expect such function declarations to be classified as ES5~ES6. Then, according to the state machine, a program like: function f(g) { //not the following will produce inconsistent results among common browsers if (!g) { function g() {return 1} } else if (typeof g !== 'function') { function g() {return 2} } return g; } will be processed using the (implementation extended) ES5 specification and both f and g would presumably be non-strict functions. If you wanted the above to be processed as ES6 code you would need to add some ES6-only features such as: let ES6; or use some other forced opt-in such as a version in the MIME type. The above is exactly analogies to how any standard ES5~ES6 features would be treated. Allen -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Improving Function.prototype.bind
On Fri, Jan 6, 2012 at 10:02 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: [...] 1. everyone can WeakMap = function () {}; anywhere Again, no they can't because all whitelisted global variables are unassignable. it's a var WeakMap in the global scope ... still talking about your shim, probably I am missing some dependency? It's easy to miss. WeakMap appears as a whitelisted global at http://code.google.com/p/es-lab/source/browse/trunk/src/ses/whitelist.js#146 At http://code.google.com/p/es-lab/source/browse/trunk/src/ses/startSES.js#1062we place all these whitelisted globals on the sharedImports object as well as redefine the property as non-writable non-configurable on the global object. At http://code.google.com/p/es-lab/source/browse/trunk/src/ses/startSES.js#1294we freeze sharedImports and all objects reachable from it by transitive prototype and reflective property traversal. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
(This grew out of a conversation Allen and I had yesterday -- great to see it developed.) One thing to make clear: ES5~EAS6: The construct has identical syntax and static semantics in both ES5 and ES6, but differing semantics. For example, accessing a formal parameter after an assignment to the corresponding element of the function's arguments object. This is something we propose to do with completion reform, and also until this year for typeof null. It's clear we can't get away with changing typeof null == null. Even with full opt-in, it's a runtime migration hazard (one of the five fingers of fate). I withdraw it -- I'm the one who proposed it in lieu of an Object.isObject predicate -- but I do not think we should add Object.isObject either. Rather, we need to rethink reflection on types in light of not only null vs. object, but value types/proxies. I'd rather not rush that. In the mean time, and for lo these 16 years (heading toward 17!), developers have coped and can continue to do so with typeof x == object x === null or simpler (!x, x == null, other context-specialized combinations). In general, the latest new syntax is its own opt-in thinking, with Allen's state machine approach, means our five fingers of fate have to be small enough that we can get away with them. At least Mark and I believe completion reform (making the completion value depend on a statically decidable expression-statement) is the only such finger we can get away with folding right now. If you want to explicitly force ES6 processing put a: let ES6; Or (no quotes) use strict; I think we want this pragma supported, not only the string-literal expression-statement directive. at the top of the source file. If you want to explicitly force ES5 processing put a: with (5); at the top of the source file That will potentially deoptimize the top level for some engines, but maybe it doesn't matter. I don't expect it to catch on ;-). /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 6, 2012, at 11:23 AM, Mark S. Miller wrote: AFAICT, this agrees with my analysis of what your proposal means. How does this not result in three modes? Counting modes is not productive, is it? All major implementations have extended ES5. It's likely extensions will continue to precede standardization. Do these make ongoing new modes? Rather, we should minimize the state machine and how we talk about it. We could generalize it using Curr, Next, CurrNext, and Curr-Next labels. /be On Fri, Jan 6, 2012 at 9:45 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Jan 6, 2012, at 8:03 AM, Mark S. Miller wrote: No sorry, I just spotted the flaw. The observable difference is that a conforming browser is not required by the (ES5 + ES6) specs to provide any non-triggering ES6 features for program #2. In that case, we again have three mode. For example, since legacy constrains us from making nested named function declarations a triggering feature, if program #2 has a nested named function and the browser rejected it, that browser would still conform to both the ES5 and ES6 spec. Implementations that currently support extensions to ES5 (and wish to continue to support them) must classify their extensions into one of the four categories I identified and then process them according to the state machine. Because no currently implementation of function declarations within blocks (that I'm aware of) matches the ES6 lexical scoping semantics, it would expect such function declarations to be classified as ES5~ES6. Then, according to the state machine, a program like: function f(g) { //not the following will produce inconsistent results among common browsers if (!g) { function g() {return 1} } else if (typeof g !== 'function') { function g() {return 2} } return g; } will be processed using the (implementation extended) ES5 specification and both f and g would presumably be non-strict functions. If you wanted the above to be processed as ES6 code you would need to add some ES6-only features such as: let ES6; or use some other forced opt-in such as a version in the MIME type. The above is exactly analogies to how any standard ES5~ES6 features would be treated. Allen -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 6, 2012, at 11:23 AM, Mark S. Miller wrote: AFAICT, this agrees with my analysis of what your proposal means. How does this not result in three modes? I guess I don't understand exactly what you mean by a mode or why the number of modes is particularly interesting. From an implementation perspective, I suppose you consider each state in my FSM a mode in which case we have 4 processing modes. Or If you are using mode to classify the semantics of arguments and assignment to undeclared identifiers then there are two modes: strict and non-strict If you are using mode to classify what can occur in a StatementList there are three modes: ES5, ES5-strict, ES-6. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
Rather, we should minimize the state machine and how we talk about it. We could generalize it using Curr, Next, CurrNext, and Curr-Next labels. I’m awfully sorry for belaboring this point. But the labels and the quote below don’t go together. Quoting Brendan: - ES6 is a superset of ES5.strict. That's always been promised. Then I would only expect two labels: ES6 and non-strict ES6-only = (a subset of) ES6 ES5-only = only possible for non-strict constructs = non-strict ES5ES6 = (a subset of) ES6 ES5~EAS6 = not possible (“The construct has identical syntax and static semantics in both ES5 and ES6, but differing semantics.”) -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 6, 2012, at 11:52 AM, Brendan Eich wrote: (This grew out of a conversation Allen and I had yesterday -- great to see it developed.) One thing to make clear: ES5~EAS6: The construct has identical syntax and static semantics in both ES5 and ES6, but differing semantics. For example, accessing a formal parameter after an assignment to the corresponding element of the function's arguments object. This is something we propose to do with completion reform, and also until this year for typeof null. It's clear we can't get away with changing typeof null == null. Even with full opt-in, it's a runtime migration hazard (one of the five fingers of fate). I withdraw it -- I'm the one who proposed it in lieu of an Object.isObject predicate -- but I do not think we should add Object.isObject either. Rather, we need to rethink reflection on types in light of not only null vs. object, but value types/proxies. I'd rather not rush that. In the mean time, and for lo these 16 years (heading toward 17!), developers have coped and can continue to do so with typeof x == object x === null or simpler (!x, x == null, other context-specialized combinations). In general, the latest new syntax is its own opt-in thinking, with Allen's state machine approach, means our five fingers of fate have to be small enough that we can get away with them. At least Mark and I believe completion reform (making the completion value depend on a statically decidable expression-statement) is the only such finger we can get away with folding right now. If you want to explicitly force ES6 processing put a: let ES6; Or (no quotes) use strict; I think we want this pragma supported, not only the string-literal expression-statement directive. If we end up with all of ES6 being a super set of ES5 strict, then I don't see a lot value in saying: use strict; I would think that: use ES6; //or use version 6; etc would better express the user intent. BTW, I would interpret this as meaning at least ES6 and still do feature driven version detection of future versions using an expanded state machine. at the top of the source file. If you want to explicitly force ES5 processing put a: with (5); at the top of the source file That will potentially deoptimize the top level for some engines, but maybe it doesn't matter. I don't expect it to catch on ;-). Other ES5 opt-ins at the top level include: var arguments; function ES5(yes,yes){}; These probably won't cause any deoptimization. However, I agree that it would be rare for someone to actually need to do this. The intent was more to emphasize that the way you force a particular spec-level interpretation is to code something that is unique to that spec-level. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 6, 2012, at 12:09 PM, Axel Rauschmayer wrote: Rather, we should minimize the state machine and how we talk about it. We could generalize it using Curr, Next, CurrNext, and Curr-Next labels. I’m awfully sorry for belaboring this point. But the labels and the quote below don’t go together. Quoting Brendan: - ES6 is a superset of ES5.strict. That's always been promised. Then I would only expect two labels: ES6 and non-strict You're counting different beans from Mark's modes and from Allen's states. The reason the state machine matters is implementation (including the fine spec, the normative implementation). Authors can think of writing non-strict ES5 or lower, or ES5 strict -- or ES6 if they use a bit of novelty. Different beans again. I'm not sure what informs your label count expectation. In writing JS for the web over the next several years, you might have to worry quite a bit about ES5 strict vs. ES6. You can't just assume ES6 works everywhere that ES5 strict works. /be ES6-only = (a subset of) ES6 ES5-only = only possible for non-strict constructs = non-strict ES5ES6 = (a subset of) ES6 ES5~EAS6 = not possible (“The construct has identical syntax and static semantics in both ES5 and ES6, but differing semantics.”) -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 6, 2012, at 12:25 PM, Allen Wirfs-Brock wrote: On Jan 6, 2012, at 11:52 AM, Brendan Eich wrote: Or (no quotes) use strict; I think we want this pragma supported, not only the string-literal expression-statement directive. If we end up with all of ES6 being a super set of ES5 strict, then I don't see a lot value in saying: use strict; The value is that the string literal is non-breaking in pre-ES5 implementations, which has been a source of real bugs (concatenation, too-early adoption). Explicit opt in via use strict; seems better to me than anything with a version number in it. More below. I would think that: use ES6; //or use version 6; etc would better express the user intent. BTW, I would interpret this as meaning at least ES6 and still do feature driven version detection of future versions using an expanded state machine. While the ECMA editions will be numbered (unpredictably!), and RFC4329 points toward post-hoc standardization of the ;version= MIME type parameter, I do not think we should embed version numbers in pragmas. We could, certainly. That was the plan of record until recently. It matches the ;version= progression we're likely to want anyway, to hide new code from being loaded by old browsers with inevitable syntax errors whose reporitng slows the futile loads even further. But I'd rather leave ;version= to the MIME type parameter, which is just a post-hoc reflection of ECMA's edition numbering. This reduces the tendency to think of versions, modes, and the like. It's a human factors thing. Versions suck, Hixie and Anne and others were right to push back on them, even if they didn't solve the forward compatibility problem (no one has) or are in denial about HTML5 (with 5) :-P. Other ES5 opt-ins at the top level include: var arguments; function ES5(yes,yes){}; These probably won't cause any deoptimization. However, I agree that it would be rare for someone to actually need to do this. The intent was more to emphasize that the way you force a particular spec-level interpretation is to code something that is unique to that spec-level. Sure. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
Then I would only expect two labels: ES6 and non-strict You're counting different beans from Mark's modes and from Allen's states. The reason the state machine matters is implementation (including the fine spec, the normative implementation). Authors can think of writing non-strict ES5 or lower, or ES5 strict -- or ES6 if they use a bit of novelty. Different beans again. Ah, got it! You want ECMA-262 version 6 to allow an à la carte approach: implementors can choose between non-strict ES5, strict ES5, ES6, etc. I'm not sure what informs your label count expectation. In writing JS for the web over the next several years, you might have to worry quite a bit about ES5 strict vs. ES6. You can't just assume ES6 works everywhere that ES5 strict works. I was thinking about how to specify only (exclusively) an ES6 environment. You pretend to live in a “perfect ES6 world” and then only have two labels. There are two ways out of this world: - Non-ES6 environments for implementors: refer to ECMA-262 version 5.1. - Non-ES6 environments for developers: simulate ES6 (via static compilation, dynamic compilation, etc.). -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
The issue is *how* the spec and implementations decide what is supported, and when to raise an error on new syntax mixed (after) old non-strict code (e.g., 'with'). Ah, OK. I thought that one would be able to lump together ES5.non-strict and all prior ES versions on one hand and ES6 and ES5.strict on the other hand. But it makes sense that even if developers (engine users) are presented with something simple, implementors have to take care of many more details. -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RFC: Empowered data - unification of code block and object literal (and class)
This proposal tries not to add new entities into the language, it only tries to take what already is there and reusing it mercilessly. Also number of abstractions is lowered, since some of them could be implemented with existing ones, with minimal changes. The result is compact, lesser, more uniform and much more powerful language. ;-) Forward-compatible. (The whole text is here as HTML: http://blog.herby.sk/blosxom/Programming/ES-next/empowered-data.html It is long, but imnsho rich. Please, give it a chance if you'll feel for a few minutes of reading. It is also included below, but without formatting, to allow replies. Thank you, Herby) Motivation. Blocks of code enclosed in curly braces were of two natures in ES3 and ES5 - there were code blocks, containing sequence of instructions to perform, and there was the object literal, which contained recipe for building a structured piece of data. ES.next introduced some powerful additions to the object literal, introduced new use for it (.{...} and | {...} operations) and brought in a new type of {...} block - the class block. The class block borrows many new features of object literal, but itself is something in-between. Driven by the feeling that having more types of {...} source code constructs brings more confusion led to the thoughts about their nature and their similarities. This proposal wants to take this train of thought to the extreme by proposing only two types of brave new curly block constructs with strict role split - the imperative one for control flow and the declarative one for data structures, while building on similarities between them and radically empower the declarative one in the process, and not losing forward compatibility (by this I mean old-style constructs work in the new proposal). Classes are made as one case of the declarative construct with class-specific extensions, changing existing class syntax very slightly and not losing any semantics. Curly blocks are similar. Reuse for much power with few features. A simple code block: { x = 4; receiver.f(x); function g() { do { nothing; } while (false); } x++; const prop = 5; if (x5) { process.exit(); } x-- } Basic structure of this block is: there are simple statements, which are terminated by a semicolon (ignoring general semicolon insertion here). The last simple statement in a code block does not need a semicolon, though it can have it. These statements include assignment and function call. Then there are structured statements which do not need to be ended with semicolon (do-while is a nasty exception), since they are ended with a sub-block. These are if/else, while loops, function declarations etc. Not that this is correct explanation of code block structure (I for example ignore cases where if/else/while/... sub-statements are simple statments, not sub-blocks. For now, let us assume there are always sub-blocks). I also intentionally dismissed variable declarations, since they are not needed for this topic and would make things a little more complicated (look at that const line as an assignment ;-) ). Now, for the simple object literal (with ES.next extensions): { x: 4, g() { do { nothing; } while (false); } y: { foo: bar }, get prop () { return 5; } z: 0 } Basic structure of this block is: there are simple productions, which are terminated by a colon. The last simple production in a literal block does not need a colon, though it can have it. These productions are property initializations. Then there are enhanced productions which do not need to be ended with colon, since they are ended with a sub-block. These are get, set and method declarations. Even when the range of possible building elements of object literal is smaller than that of the code block, the similarities can be seen pretty well. There is undoubtful similarity between x = 4; and x: 4,, not only syntactical, but semantical, too. There is strong syntactical similarity between declaration of function g in code block and method g in the literal. Semantically it is also pretty similar, though not as much as the previous case. Previous examples showed that there are formally (simple-simple, structured-enhanced), syntactical and functionally similar pairs of constructs between code block and object literal. These elements are, more-or-less, about the same thing. The difference between them is given by the context: assignment and function declaration do actions (they are imperative), field specification and method specification produce data (they are declarative). It can be said, with lot of grains of salt, that code block is (ordered) collection of imperative elements, simple, semicolon delimited, as well as structured, undelimited and object literal is (unordered) collection of declarative elements, simple, colon delimited, as well as structured, undelimited, but matching elements appear in both. This strawman is
Re: ES6 doesn't need opt-in
On Jan 6, 2012, at 1:35 PM, Axel Rauschmayer wrote: The issue is *how* the spec and implementations decide what is supported, and when to raise an error on new syntax mixed (after) old non-strict code (e.g., 'with'). Ah, OK. I thought that one would be able to lump together ES5.non-strict and all prior ES versions on one hand and ES6 and ES5.strict on the other hand. Notice that two of the four states contain possible outcome terminate with Error: invalid combination of ES5 and ES6 features These are the states labeled ES5 and ES6. It should be clear that you need more than two states to judge whether a given hunk of code is ES5 non-strict (or lower) -- the default unversioned script JS we know today -- or ES5-strict or higher. To have only two states in the machine, you would need version-based opt-in. But don't worry about counting states. Count minimal or even non-minimal modes if you like ;-). But it makes sense that even if developers (engine users) are presented with something simple, implementors have to take care of many more details. A point that I flog often. The few and skilled implementors should take some complexity on behalf of the whole user base, provided that complexity in implementation and specification saves the bulk of users enough by simplifying migration and adoption. IMHO we are onto something good here. The complexity for the implementors does not too bad (I'm looking at it right now for SpiderMonkey), and the user-facing wins are huge. /be___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
Axel, thanks. This is the critical point, so no apologies needed for belaboring. Allen, what I mean is exactly what Axel says here. Look at it another way. Right now we have two normative modes: ES5 strict and ES5 non-strict. State machine aside, ES6 introduces a new single mode normative spec. If the state machine may delegate to any of these three normative specs we have three modes. If the state machine may only delegate to ES5-non-strict or ES6, i.e., if the ES5-strict spec becomes dead code as of conformance with state machine + ES6 spec, then we have two modes. To get this effect, we need only classify ES5's use strict; directive as ES6-only. If any objection to doing so has been stated, I missed it. Is there a reason not to do so? It's a one line change that leaves the rest of your proposal unperturbed and solves this problem. On Fri, Jan 6, 2012 at 12:09 PM, Axel Rauschmayer a...@rauschma.de wrote: Rather, we should minimize the state machine and how we talk about it. We could generalize it using Curr, Next, CurrNext, and Curr-Next labels. I’m awfully sorry for belaboring this point. But the labels and the quote below don’t go together. Quoting Brendan: - ES6 is a superset of ES5.strict. That's always been promised. Then I would only expect two labels: ES6 and non-strict ES6-only = (a subset of) ES6 ES5-only = only possible for non-strict constructs = non-strict ES5ES6 = (a subset of) ES6 ES5~EAS6 = not possible (“The construct has identical syntax and static semantics in both ES5 and ES6, but differing semantics.”) -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Fri, Jan 6, 2012 at 12:25 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: [...] Other ES5 opt-ins at the top level include: var arguments; function ES5(yes,yes){}; Please stop calling these ES5 opt-ins. They preclude the Program from being strict, and so are forcing ES5-not-strict. Non confusing names for this are: ES5-non-strict Non-strict ES3 By continuing to call this simply ES5 while precluding the program from being an ES5-strict program, you confuse the crucial issue I'm trying to clarify. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Fri, Jan 6, 2012 at 12:29 PM, Brendan Eich bren...@mozilla.com wrote: On Jan 6, 2012, at 12:09 PM, Axel Rauschmayer wrote: Rather, we should minimize the state machine and how we talk about it. We could generalize it using Curr, Next, CurrNext, and Curr-Next labels. I’m awfully sorry for belaboring this point. But the labels and the quote below don’t go together. Quoting Brendan: - ES6 is a superset of ES5.strict. That's always been promised. Then I would only expect two labels: ES6 and non-strict You're counting different beans from Mark's modes and from Allen's states. Hi Brendan, as I read it, Axel captures exactly the two modes I have in mind. The reason the state machine matters is implementation (including the fine spec, the normative implementation). Authors can think of writing non-strict ES5 or lower, or ES5 strict -- or ES6 if they use a bit of novelty. Different beans again. I'm not sure what informs your label count expectation. In writing JS for the web over the next several years, you might have to worry quite a bit about ES5 strict vs. ES6. You can't just assume ES6 works everywhere that ES5 strict works. The issue is: What does it mean for a browser to be standards compliant once it is fully conformant with ES6? Yes, of course there will be a long phase of partial ES6 compliance as features are incrementally rolled out. Just as there was with ES5. But during this period, no one claims full conformance with ES6, so standards compliance mean only compliance with ES5. To be standards compliant once one is ES6 compliant, the state machine + ES6 keeps some portion of the ES5 spec as a live normative spec because it is reachable from the state machine. The only question is: Which portion is reachable? With Allen's plan, all of it. With the one line revision Axel and I have in mind, the ES5-strict spec stops being reachable as normative for ES6 compliant browsers. It is dead code that can be considered garbage. In the ES6 era, I hope to be able to say ES5-strict is dead. Long live ES6!. However, ES5-non-strict (or non-strict, or ES3) will continue to live for the foreseeable future. It will probably outlive most of us. /be ES6-only = (a subset of) ES6 ES5-only = only possible for non-strict constructs = non-strict ES5ES6 = (a subset of) ES6 ES5~EAS6 = not possible (“The construct has identical syntax and static semantics in both ES5 and ES6, but differing semantics.”) -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss