I wrote a (new) script that generates a regular expression that matches valid
JavaScript identifiers as per ECMAScript 5.1 / Unicode v6.2.0.
http://mathiasbynens.be/demo/javascript-identifier-regex
Then, I made it do the same thing according to the latest ECMAScript 6 draft,
which refers to
Hello everyone,
What's the point about optional named arguments support, please?
ES6? ES7? abandoned?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
While debugging a V8 issue I just realised another incompatibility
with introducing lexical function declarations in sloppy mode that I
think we haven't observed yet. Consider the following code:
function f() {
var x = 0
try {
throw 1
} catch (x) {
eval(function g() { return x })
See Bug 1593
In ES5, an expression such as:
obj.m(arg)
is visibly evaluated in this order:
1. thisValue - evaluate(obj)
2.f - thisValue.[[Get]](m);
2.apossible visible side-effets of getting property m
3.arg1 - evaluate(arg)
3.a possible visible side-effects of
On 8/19/2013 9:33 AM, Allen Wirfs-Brock wrote:
thisObj.[[Invoke]](propertyKey, function, argumentList)
This could allow [[Invoke]] to trap `call` and `apply`, if propertyKey
was allowed to be undefined.
___
es-discuss mailing list
On Aug 19, 2013, at 8:38 AM, Andreas Rossberg wrote:
While debugging a V8 issue I just realised another incompatibility
with introducing lexical function declarations in sloppy mode that I
think we haven't observed yet. Consider the following code:
function f() {
var x = 0
try {
On Mon, Aug 19, 2013 at 4:31 AM, Michaël Rouges
michael.rou...@gmail.com wrote:
Hello everyone,
What's the point about optional named arguments support, please?
ES6? ES7? abandoned?
Someone else should feel free to correct me, but I *think* that
explicit optional named arguments have been
On 19 August 2013 19:02, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Aug 19, 2013, at 8:38 AM, Andreas Rossberg wrote:
While debugging a V8 issue I just realised another incompatibility
with introducing lexical function declarations in sloppy mode that I
think we haven't observed yet.
On Aug 19, 2013, at 9:39 AM, Brandon Benvie wrote:
On 8/19/2013 9:33 AM, Allen Wirfs-Brock wrote:
thisObj.[[Invoke]](propertyKey, function, argumentList)
This could allow [[Invoke]] to trap `call` and `apply`, if propertyKey was
allowed to be undefined.
I don't really want to get us off
From: Mark S. Miller [erig...@google.com]
No. Assuming that p and q are both promises and that q is pending, p is
resolved to q when either p adopts q or p accepts q. From the .then
perspective these are the same, so we'd say p follows q or p is resolved to
q. In neither care would p.then
Er, replace `notAcceptedAndNotResolved` with `resolvedButNotAccepted`. X_x
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
In https://mail.mozilla.org/pipermail/es-discuss/2013-August/032724.html (plus
following errata) I created the following promise:
```js
var foreverPending = new Promise(() = {});
var acceptedButNotResolved = Promise.fulfill(foreverPending);
```
This brings up the horrible point that
More data about whether changing this would break anything:
I reported https://code.google.com/p/v8/issues/detail?id=691 in May 2010.
It remains open -- probably because it has caused few actual problems.
On Mon, Aug 19, 2013 at 10:44 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Aug
And because it remains open, whereas FF, Safari, and old Opera followed
ES5, the cross-browser web must be compatible with either decision.
On Mon, Aug 19, 2013 at 11:15 AM, Mark S. Miller erig...@google.com wrote:
More data about whether changing this would break anything:
I reported
So what? This isn't bad. It's just what happens in implementations where
you don't have timeouts enforced by the system.
C'est la vie.
On Monday, August 19, 2013, Domenic Denicola wrote:
In https://mail.mozilla.org/pipermail/es-discuss/2013-August/032724.html(plus
following errata) I created
I don't really understand your response. What timeouts are you talking about?
(Wrong thread perhaps?)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Mon, Aug 19, 2013 at 7:20 PM, Andreas Rossberg rossb...@google.comwrote:
On 19 August 2013 19:02, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Does V8 crash on the simpler example? Does it produce a ReferenceError
(not conforming to ES5) on the call to g()? You're implementation may be
Promise.fulfill/PromiseSource#fulfill made sense when there was no unwrap on
the input side of Promise#then:
*then:*
```js
var foreverPending = new Promise(() = {});
Promise.fulfill(foreverPending).then(x = assert(x === foreverPending))
Promise.resolve(foreverPending).then(() = { /* never
On Mon, Aug 19, 2013 at 12:50 PM, Ron Buckton rbuck...@chronicles.org wrote:
Promise.fulfill/PromiseSource#fulfill made sense when there was no unwrap on
the input side of Promise#then:
Exactly.
With all the changes to Promise (addition of Promise#flatMap, recursive
unwrap on input side of
On Mon, Aug 19, 2013 at 11:13 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Tab and I think the solution to this is to:
- Kill `Promise.fulfill`, and of course also the `fulfill` option to the
promise initializer.
- Change `flatMap` to operate on resolved values, so that
With all the changes to Promise (addition of Promise#flatMap, recursive
unwrap on input side of Promise#then, etc.), it does seem that fulfill's
use case has become a bit muddled. I'll admit to still being partial to the
earlier design (fulfill/resolve/reject, adopt without recursive
Let's separate two forms of complexity:
a) Complexity visible to those who must use, implement, or understand the
full API including .flatMap.
b) Complexity visible to those who only use, implement, or understand the
subset without .flatMap.
The main beauty of AP2 is that it minimizes the
On Mon, Aug 19, 2013 at 6:20 PM, Mark S. Miller erig...@google.com wrote:
Let's separate two forms of complexity:
a) Complexity visible to those who must use, implement, or understand the
full API including .flatMap.
b) Complexity visible to those who only use, implement, or understand the
Mark, I completely agree with you. However, I think this somewhat ignores the
issue of this thread. The problem with AP2, even completely ignoring `flatMap`,
comes when you consider the behavior of the `Promise.fulfill` method. Namely,
what does this code do?
```js
var foreverPending = new
I agree that an AP2 system, which is what we are discussing, should not
have a method named .fulfill for the reasons you state. A promise which, at
the AP2.flatMap level is accepted or adopted is, at the AP2.then level
resolved. I suggest the method in question be called .resolve, that it
accept,
Thanks Mark.
To clarify my overly brief interjection, I tend to favor the conceptual
simplicity of the earlier DOM API. Specifically:
- no flatMap
- the output of then is single-unwrapped
- no recursive unwrapping
I find it more simple from a conceptual standpoint because each promise
simply
Implementation:
function unwrap(value) {
return Promise.resolve(value).then(v = isPromise(v) ? unwrap(v) :
v);
}
Promise.when = value = unwrap(value);
Test:
var promise = new Promise(r = {
r.fulfill(new Promise(r = { r.fulfill(1); }));
});
Hi Kevin, I misinterpreted you. By earlier, I thought you were referring
to the promise APIs in actual use which are compatible with Promises/A+.
These do not create promises-for-promises (auto-flattening or auto-lifting
depending on how you want to think about it) and they recursively unwrap
How does what you mean by .then here differ from .flatMap? If it is the
same, why not rename your .then to .flatMap and rename your .when to .then ?
On Mon, Aug 19, 2013 at 8:14 PM, Kevin Smith zenpars...@gmail.com wrote:
Implementation:
function unwrap(value) {
return
29 matches
Mail list logo
