Re: Standard modules?
Le 20/01/2014 23:16, Kevin Reid a écrit : SES needs to visit every 'primordial' / 'singleton' object to ensure they're made immutable and harmless. (Other 'meta' code might also benefit though I don't know of any examples offhand.) This job is easier if all such objects are reachable via traversing data properties. ES5 contains only one object which this is not true of: Beware, I've heard that the browser contains many more of these objects. See discussion starting at https://bugzilla.mozilla.org/show_bug.cgi?id=900034#c4 In a nutshell, WebIDL defines the NoInterfaceObject which, when reified in ECMAScript means that a prototype object exists, but it can't be found via Interface.prototype (since Interface is not defined as a global). I imagine the only way to find these is create an instance and the Object.getPrototypeOf. It's apparently used in WebGL sometimes. I imagine there is a complete repository of WebIDL files somewhere (Moz/Blink codebase, maybe W3C, maybe alongside the WebGL spec) you can use to list all of these interfaces. How to create the different instances is another story. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New ES6 spec draft (Rev 22, Jan 20, 2014)
I really like the way the ES6 spec is coming together. Generally the way in
which abstract ops are used and internal methods are specified is much
clearer and more uniform in ES6 than in ES5. Also, the table of contents is
much better structured. I like your classification according to indexed
collections, keyed collections, control abstraction objects, reflection,
etc. These editorial issues are not always fully appreciated, but +1 to
them.
Cheers,
Tom
2014/1/21 Allen Wirfs-Brock al...@wirfs-brock.com
The draft is available at
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#january_20_2014_draft_rev_22
Big news: Promise and Module Loading/Linking. Still a few loose ends, but
we're getting there.
Changes include:
- Promises
- Module loading/linking semantics
- Internal Tasks
- Realm Objects
- Loader Objects
- updated with binding for unscopable names as discussed at Sept 2013
meeting
- An unscopables object is now an ordinary object whose own property
keys are the unscopable names.
- Fixed sticky mode bugs in RegExpExec
- Provided algorithm for RegExp.prototype.replace and updated other
RegExp methods
- Fixed RegExp matcher algoritm to normalize results of Unicode mode
matches back to UTF-16
- Grammar parameter tweaks related to use of yield in generator
parameters.
- Simplified eval/arguments restrictions. They never are applied in
non-strict code
- Added tail call detection for arrow functions with expression bodies
- clarified unicode escaping in IdentifierNames and keywords
- The default class constructor definition is now
“constructor(...args) {return super (...args);)” if one is not explicitly
provided (adding explicit “return” is the change)
- Fixed Invoke abstract operation to correctly handle invokes on
primitive values. Implementations of built-ins that are * specified using
Invoke should make sure they work correctly in cases where Invoke might be
validly applied to a primitive
- Function.prototype.toMethod, replaces RebindSuper abstraction
operation with CloneMethod
- Eliminated comparator optional argument to Map and Set constructor
- Removed vague overflow/underflow requirements from Math.Hypoth
- Creating a Proxy requires use of new.
- No line terminator allow before the * in yield *.
- extends clause of a class declaration is now a
LeftHandSideExpression
- Completely redo of object invariants section.
___
es-discuss mailing list
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: New ES6 spec draft (Rev 22, Jan 20, 2014)
Couple of nits WRT modules: - The instantiationRequest interface is defined as having two properties: execute and deps. I believe deps should be spelled dependencies to match the naming conventions throughout the rest of the document. Besides that, there is no reason that I can see to optimize keystrokes for that property name. - The loader for the current realm is specified as a property of the global object named System. This has always bothered me for two reasons: 1) The word system does not describe the object. It is a loader, not a system. 2) The current loader is an instance of the Loader type. It is incongruent to name an instance with a capitalized identifier. I believe it would be more appropriate to provide access to the current loader via a getter on the Loader or Realm constructor. For example: Realm.loader Loader.current etc... Thanks - it's looking great! ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New ES6 spec draft (Rev 22, Jan 20, 2014)
On Tue, Jan 21, 2014 at 9:29 AM, Kevin Smith zenpars...@gmail.com wrote: 2) The current loader is an instance of the Loader type. It is incongruent to name an instance with a capitalized identifier. I believe it would be more appropriate to provide access to the current loader via a getter on the Loader or Realm constructor. For example: Realm.loader Loader.current etc... First, there are plenty of standard bindings on the global object that are not constructors and yet are capitalized -- `Math` is a prime example here. Second, there's no reason that access to a particular loader and access to the Realm or Loader constructors should be related. Third, anything in the `.current` style is introducing inexplicable magic into the platform to have the value of the property vary depending on a property that code otherwise can't observe. Fourth, there can be multiple loaders associated with a given Realm. Fifth, the binding for `System` is not a general mechanism for accessing loaders -- it is a binding for a particular one, the one provided by the host environment. it shouldn't be confused with such a general mechanism (which, as I say above, would be a bad idea anyway). Sam ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New ES6 spec draft (Rev 22, Jan 20, 2014)
On Mon, Jan 20, 2014 at 7:42 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: The draft is available at http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#january_20_2014_draft_rev_22 Big news: Promise and Module Loading/Linking. Still a few loose ends, but we're getting there. Changes include: - Promises - Module loading/linking semantics - Internal Tasks - Realm Objects - Loader Objects We have been implementing module loading based on and giving feedback to https://github.com/jorendorff/js-loaders. I was under the impression that the standards committee had temporarily delegated the module-loading to js-loaders. Were we wrong or can someone clarify what we should be paying attention to? jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New ES6 spec draft (Rev 22, Jan 20, 2014)
John, js-loaders is both the initial spec. draft and the initial prototype of the module subsystem. What we have now is the integration of the that initial draft into the actual ES6 spec. In doing that there is some editorial renaming and refactoring intended to improve the spec. clarity and the logical layer of the entire ES6 spec. There shouldn't be any semantic differences, except where there were ambiguities or open issues and those we will be discussing. Issues relating to the specification need to go through bugs.emcascript.org so I can track and resolve them them for the official specification. I just added a modules component to the Draft for 6th Edition product. I suggest you run all feature/specification related issues through there. Dave, Sam, and Jason will all be CC'd on those. Issues relating specifically to Jason's prototype can probably continue to be handled on github. Allen On Jan 21, 2014, at 7:43 AM, John Barton wrote: On Mon, Jan 20, 2014 at 7:42 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: The draft is available at http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#january_20_2014_draft_rev_22 Big news: Promise and Module Loading/Linking. Still a few loose ends, but we're getting there. Changes include: Promises Module loading/linking semantics Internal Tasks Realm Objects Loader Objects We have been implementing module loading based on and giving feedback to https://github.com/jorendorff/js-loaders. I was under the impression that the standards committee had temporarily delegated the module-loading to js-loaders. Were we wrong or can someone clarify what we should be paying attention to? jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standard modules?
On Jan 20, 2014, at 11:46 PM, Andy Wingo wrote:
On Mon 20 Jan 2014 18:39, Brendan Eich bren...@mozilla.com writes:
Allen Wirfs-Brock wrote:
It isn't clear that there much need for a global name for
GeneratorFunction. If you really eed to access it can always get it
via:
(function *() {}).constructor
Does this present a hazard for CSP, which provides policy controls
governing Function?
Relevant spec:
http://w3c.github.io/webappsec/specs/content-security-policy/csp-specification.dev.html#script-src
I guess CSP needs to be updated to have similar language for
GeneratorFunction as for Function. As Allen mentions, though it doesn't
have a name it is accessible.
I just took a look at SM and V8 and it seems both of them respect CSP
for the GeneratorFunction constructor, though both are lacking test
cases. Not sure how to trigger such a test case without a browser.
I would assume that the actual test would normally be done at the level of the
implementation that compiles (or executes) such code and not in the public API
that exposes that capability.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Standard modules?
On Jan 20, 2014, at 2:16 PM, Kevin Reid wrote:
On Sun, Jan 19, 2014 at 7:21 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
It isn't clear that there much need for a global name for GeneratorFunction.
If you really eed to access it can always get it via:
(function *() {}).constructor
(as the always helful generator UMO diagram at
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-generatorfunction-objects
tells us)
SES needs to visit every 'primordial' / 'singleton' object to ensure they're
made immutable and harmless. (Other 'meta' code might also benefit though I
don't know of any examples offhand.)
This job is easier if all such objects are reachable via traversing data
properties.
ES5 contains only one object which this is not true of: [[ThrowTypeError]].
This would have been fine since [[ThrowTypeError]] as specified is immutable
and harmless, but in practice many implementations have bugs or extensions
which make it mutable. We had to add a special case for it to ensure that it
was traversed.
https://code.google.com/p/google-caja/issues/detail?id=1661
https://codereview.appspot.com/8093043/diff/19001/src/com/google/caja/ses/repairES5.js
It would be nice if there was some way in ES6 to make sure SES doesn't miss
any objects — either that every primordial object is reachable via data
properties (more precisely: that there are no preexisting objects which are
reachable only by way of executing some program construct; e.g. Array is
reachable by [].constructor, but is also named Array in the standard
environment), or there is some other way to enumerate them.
In ES6 there are more things like [[ThrowTypeError]] including a number
lintroduced in support of promises and modules. I'm seriously thinking that
they should be defined as being immutable.
All intrinsics (the ES6 term for primordials) are/will be enumerated in the
ES6 spec.
I assume that in the ES6 context that SES would use Realms and module loaders
to implement its sandbox so you should probably follow those spec. to make sure
they do what you need.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
SameValueZero comparator and compatibility
The implementations of Maps and Sets in the wild that I am aware of (IE11, SpiderMonkey, and V8 behind a flag) all currently use SameValue as comparator while the spec calls for SameValueZero. It seems like either the implementations need to update (quickly) to match the spec. before too much code depends on this, or the spec should be changed to match the implementation reality. This discrepancy has the potential to make for some hard to trace bugs, due to the otherwise near-invisibility of the -0/0 difference. Regardless of the merits of each comparator, I think at this point it's more important that everyone (implementers + spec.) is following the same marching orders. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New ES6 spec draft (Rev 22, Jan 20, 2014)
First, there are plenty of standard bindings on the global object that are not constructors and yet are capitalized -- `Math` is a prime example here. Math (and Reflect, JSON, etc) are functioning not as objects with per-instance state, but as namespaces. Infinity is a value object, but doesn't carry per-instance state like a loader does. Fifth, the binding for `System` is not a general mechanism for accessing loaders -- it is a binding for a particular one, the one provided by the host environment. it shouldn't be confused with such a general mechanism (which, as I say above, would be a bad idea anyway). Granted. My point was just that it's awkward to have an object which is an instance of a provided type, carrying per-instance state, denoted by a capitalized global property name. And that System as a name (by itself) doesn't describe the concept. Just my opinion - no big deal. The module design is very lovely. : ) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: SameValueZero comparator and compatibility
The most reliable way to get the implementations to conform is to contribute a test262 test. As for how to contribute a test262 test, I am still confused about the situation and leave it for others to comment. On Tue, Jan 21, 2014 at 9:58 AM, Brandon Benvie bben...@mozilla.com wrote: The implementations of Maps and Sets in the wild that I am aware of (IE11, SpiderMonkey, and V8 behind a flag) all currently use SameValue as comparator while the spec calls for SameValueZero. It seems like either the implementations need to update (quickly) to match the spec. before too much code depends on this, or the spec should be changed to match the implementation reality. This discrepancy has the potential to make for some hard to trace bugs, due to the otherwise near-invisibility of the -0/0 difference. Regardless of the merits of each comparator, I think at this point it's more important that everyone (implementers + spec.) is following the same marching orders. ___ 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: SameValueZero comparator and compatibility
On Jan 21, 2014, at 9:58 AM, Brandon Benvie wrote: The implementations of Maps and Sets in the wild that I am aware of (IE11, SpiderMonkey, and V8 behind a flag) all currently use SameValue as comparator while the spec calls for SameValueZero. It seems like either the implementations need to update (quickly) to match the spec. before too much code depends on this, or the spec should be changed to match the implementation reality. This discrepancy has the potential to make for some hard to trace bugs, due to the otherwise near-invisibility of the -0/0 difference. Regardless of the merits of each comparator, I think at this point it's more important that everyone (implementers + spec.) is following the same marching orders. This was pretty throughly discussed during TC39. SameValue0 is a very intentional choice. The marching orders are the spec. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: SameValueZero comparator and compatibility
I wish there was an answer to that too ... if implementors are confused, how could developers even think about contributing there? I have expressed already my wishes for a Test Driven Development of JS specs/features but I find myself unable to help. Any hint would be appreciated. Thanks On Tue, Jan 21, 2014 at 10:03 AM, Mark S. Miller erig...@google.com wrote: The most reliable way to get the implementations to conform is to contribute a test262 test. As for how to contribute a test262 test, I am still confused about the situation and leave it for others to comment. On Tue, Jan 21, 2014 at 9:58 AM, Brandon Benvie bben...@mozilla.comwrote: The implementations of Maps and Sets in the wild that I am aware of (IE11, SpiderMonkey, and V8 behind a flag) all currently use SameValue as comparator while the spec calls for SameValueZero. It seems like either the implementations need to update (quickly) to match the spec. before too much code depends on this, or the spec should be changed to match the implementation reality. This discrepancy has the potential to make for some hard to trace bugs, due to the otherwise near-invisibility of the -0/0 difference. Regardless of the merits of each comparator, I think at this point it's more important that everyone (implementers + spec.) is following the same marching orders. ___ 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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: SameValueZero comparator and compatibility
On Jan 21, 2014, at 2:09 PM, Andrea Giammarchi wrote: I wish there was an answer to that too ... if implementors are confused, how could developers even think about contributing there? I have expressed already my wishes for a Test Driven Development of JS specs/features but I find myself unable to help. Any hint would be appreciated. Thanks Assuming that there is already spec. material (which is now the cases for almost all of ES6) one way would be proceeded approximately as follows: 1. Read the parts of the spec. you are going to implement. 2. If there aren't yet any test262 tests for that material, write some. Writing such tests will probably help in your understanding of the spec. material 3. Ask the feature champions and other interesting TC39 participants to review the tests in relationship to the spec. 4. Use the tests to drive your initial implementation of the feature. Add more test262 level tests as to proceed. 5. Contribute the tests, get other implementations to also test against them. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: SameValueZero comparator and compatibility
last 3 points are way too much high-level ... ask feature champions other TC39 participants ... how? Just trashing code in test262-discuss? On my initial implementation ... well, I can write the test accordingly with specs, it would be implementors eventually making the test green via their implementation/feature, not the other way round, right? Getting other implementations to test against the test ... I believe this should be the automatic **before any release** procedure anyone that is supposed to follow specs should do, right? How can I be sure about that? Wouldn't be wiser/simpler to put test262 files under Github instead of passing through a mailing list very hard to link against and point implementations? Thanks On Tue, Jan 21, 2014 at 3:01 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On Jan 21, 2014, at 2:09 PM, Andrea Giammarchi wrote: I wish there was an answer to that too ... if implementors are confused, how could developers even think about contributing there? I have expressed already my wishes for a Test Driven Development of JS specs/features but I find myself unable to help. Any hint would be appreciated. Thanks Assuming that there is already spec. material (which is now the cases for almost all of ES6) one way would be proceeded approximately as follows: 1. Read the parts of the spec. you are going to implement. 2. If there aren't yet any test262 tests for that material, write some. Writing such tests will probably help in your understanding of the spec. material 3. Ask the feature champions and other interesting TC39 participants to review the tests in relationship to the spec. 4. Use the tests to drive your initial implementation of the feature. Add more test262 level tests as to proceed. 5. Contribute the tests, get other implementations to also test against them. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Code compilation alternative to Function()
On Mon, Jan 20, 2014 at 4:21 PM, Gustavs Tēbergs fixplzsecr...@gmail.comwrote:
Following up with a benchmark.
(I thought of this idea while working on a parser generator library,
but unfortunately for my argument the library turned out really
fast...)
I decided to write a converter for Asm.js code to see roughly what
happens when building code expression by expression, and it gives me
existing programs to test with.
https://gist.github.com/fixplz/8529003
Results:
* I took Asm.js code from https://github.com/kripken/ammo.js as a testing
source
* Tested with Node 0.10.17 Win7 64
* The JS engine parses the source (1.6 MB) in 180 ms
* The opcode reader traverses the corresponting opcode binary (1.8 MB)
in 120 ms (the binary could be some 30% smaller by adding special case
codes)
* With conversion enabled the opcode reader takes 260 ms to convert back
to JS
The output concatenation is very fast. But it could be better.
Your `load` routine is not how I described and is inducing a ton of
cache-busting heap traffic. You need to put *all* strings in a single,
constant array and append references to those constant strings to a single
growing array. There should be no concatenations except for the final
.join(). I.e. something like:
var STRINGPOOL = ['do{', 'function', '(', ')', ...];
var KW_DO = 0;
var KW_FUNCTION = 1;
var LPAREN = 2;
var RPAREN = 3;
...
var outArr = [];
and then in order to concatenate a string to the output do something like:
outArr.push(STRINGPOOL[KW_DO]);
and then finally, after outArr contains the entire output, do:
return outArr.join('');
Really, what you need to do is to run a slight modification of your current
`load` routine *during compilation* and trace all strings that are
appended. Then uniquify all the needed strings and add them to a string
pool. Then you send down the wire:
1. The string pool.
2. A binary blob of indices into that string pool (or other opcodes).
Then your decoder can be as simple as:
var stringPool = getStringPool();
var indices = getIndices();
var outArr = [];
for (var i = 0, e = indices.length; i !== e; ++i) {
outArr.push(stringPool[indices[i]]);
}
return outArr.join('');
Really, this is a coding problem, and you just need to develop an efficient
codec for describing a string of JS. The approach in the Gist you linked is
not a very efficient codec. The codec used in the above simple loop is
probably not the most efficient, but if you add a couple special case
opcodes and/or use a cheap varint encoding for the indices (and
appropriately optimize the order of the string pool array to make good use
of it), then you can really get fast and small.
-- Sean Silva
The conversion forgoes minimizing parentheses so the output is larger
than the source (2.5 MB), so the total time of using a converter like
this would be 260 ms to convert + 300 ms to parse.
That means about 80% of the running time is taken up by conversion to
JS here. If the conversion involved something more complex, like
reading Ruby code, the proportion might decrease.
I think my point stands - this performance is undesirable. It might be
difficult to deploy web apps with dependencies on large foreign
codebases, especially on mobile devices which likely take much longer
to perform all of this.
This is combined with the fact that use of Function() seems to be
discouraged by the CSP proposal.
On the other hand - I learned a bit about execution semantics in V8
and found it effectively does what I wanted, only a little indirectly
by building a string of JS syntax instead of IR. (So the problem
severity in my mind is downgraded from mysterious action to
Function() kinda sucks.)
___
es-discuss mailing list
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: Code compilation alternative to Function()
On 22 January 2014 01:50, Sean Silva sil...@purdue.edu wrote: Your `load` routine is not how I described and is inducing a ton of cache-busting heap traffic. You need to put *all* strings in a single, constant array and append references to those constant strings to a single growing array. There should be no concatenations except for the final .join(). I.e. something like: I think that's what it already does. Using += is faster than push-and-join in isolated tests. I could cache uses of num.toString() though. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Code compilation alternative to Function()
On Tue, Jan 21, 2014 at 9:06 PM, Gustavs Tēbergs fixplzsecr...@gmail.comwrote: On 22 January 2014 01:50, Sean Silva sil...@purdue.edu wrote: Your `load` routine is not how I described and is inducing a ton of cache-busting heap traffic. You need to put *all* strings in a single, constant array and append references to those constant strings to a single growing array. There should be no concatenations except for the final .join(). I.e. something like: I think that's what it already does. Using += is faster than push-and-join in isolated tests. I could cache uses of num.toString() though. I'm not so worried about that. Rather, it is all the temporary string that are being created. For example, the single line ` app( getIdent(read16()) + '[' )` is creating at least 2 temporary strings. -- Sean Silva ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
