date:20120106

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

2012-01-06 Thread François REMY

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

2012-01-06 Thread François REMY

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

2012-01-06 Thread Erik Corry

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

2012-01-06 Thread Herby Vojčík

-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.

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:

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)

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

--
From: Brian Warner war...@lothar.com
Date: Thu, Jan 5, 2012 at 12:09 PM
To: fr...@googlegroups.com

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

2012-01-06 Thread François REMY

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:

- 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?

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)

2012-01-06 Thread Herby Vojčík

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