Re: yield and Promises
On 20/10/2011, at 23:37, Brendan Eich wrote:
On Oct 20, 2011, at 12:59 PM, Jorge wrote:
the assert_invariants() at the next line might run in another turn of the
event loop (when f() resumes), just as the callback does.
No. Nothing in JS today, since it lacks coroutines or call/cc, can suspend
under f and cause the continuation to be captured and then called in a later
event loop turn.
That's why I put the comment //might suspend execution !
*IF* it had coroutines or call/cc, then
the assert_invariants() at the next line might run in another turn of the
event loop (when f() resumes), just as the callback does.
and then, as far as I can see, the risks wrt invariants would be exactly the
same in the two cases:
//#1
assert_invariants();
function callBack () {
assert_invariants(); // perhaps yes, perhaps no. There's no guarantee.
};
setTimeout(callBack, 1e3);
return;
//#2
assert_invariants();
f(); //might suspend execution
assert_invariants(); // perhaps yes, perhaps no. There's no guarantee either.
return;
And my point is that the invariants not invariant anymore argument against
call/cc (that the node.js guys keep harping on again and again) does not hold
for this kind of async code written in cps because this kind of async code
written in cps does not guarantee it either.
On the other hand, *IF* we could suspend f(), instead of:
asyncFunction(request, cb);
function cb (e, response) {
if (e) //whatever
//our code continues here
}
we could simply write the above like this:
try {
response = asyncFunction(request); //might suspend execution
}
catch (e) {
//whatever
}
//our code continues here
And this has several (valuable, imo) advantages:
- We aren't trashing the call stack on every async call: we can finally debug
properly!
- We can (finally!) catch the exceptions where and when it matters.
- We can loop and control flow in the usual ways (at last!).
- It's the habitual style of coding that everybody knows already.
--
Jorge.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: yield and Promises
On 21/10/2011, at 11:07, Jorge wrote: And this has several (valuable, imo) advantages: - We aren't trashing the call stack on every async call: we can finally debug properly! - We can (finally!) catch the exceptions where and when it matters. - We can loop and control flow in the usual ways (at last!). - It's the habitual style of coding that everybody knows already. One more: - We won't have to keep pumping data upwards in the contexts in the closure (from the callback), and/or nesting them (both the contexts and the callbacks). -- Jorge ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: yield and Promises
You can disagree with anything if you're allowed to change the terms of the
discussion. :)
Brendan said JS is run-to-completion, which means that if you call a function
and control returns to you, no intervening threads of control have executed in
the meantime. But then you changed his example to this:
//#1
assert_invariants();
function callBack () {
assert_invariants(); // perhaps yes, perhaps no. There's no guarantee.
};
setTimeout(callBack, 1e3);
return;
Now matter how you line up the whitespace, the semantics of a function does not
guarantee that the function will be called right now. When a programmer
explicitly puts something in a function (the function callBack here), they are
saying here is some code that can be run at any arbitrary time. They are
expressing that *explicitly*. Whereas in a semantics with
fibers/coroutines/call/cc:
//#2
assert_invariants();
f(); //might suspend execution
assert_invariants(); // perhaps yes, perhaps no. There's no guarantee either.
return;
the mere *calling* of any function is *implicitly* giving permission to suspend
the *entire continuation* (of the current event queue turn) and continue it at
any point later on, after any other threads of control may have executed.
If you want to claim these two things are equivalent, I feel pretty confident
predicting this conversation will quickly descend into the Turing tarpit...
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Protocol for new and instanceof?
In a vein similar to making [] available to collections, one could make new
and instanceof available to other inheritance schemes.
For example:
// “Meta-class” for prototypes as classes/instantiable prototypes
function ProtoExemplars() {}
ProtoExamplar.prototype.{
operatorNew(...args) {
let inst = Object.create(this);
return inst.constructor(...args);
},
operatorInstanceof(lhs) {
return this.isPrototypeOf(lhs);
}
};
--
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: yield and Promises
On Oct 21, 2011, at 9:34 AM, John J Barton wrote: Can anyone summarize how these proposals relate to Kris Kowal / Kris Zyp / Mark Miller Q library: https://github.com/kriskowal/q Did you see https://github.com/kriskowal/q/tree/master/examples/async-generators yet? In my experience, reasoning about the code was much easier with Q than without Q. (Not something I found in trying generators). In order to say something that isn't subjective yet content-free other than negative, what was hard to reason about, and why? Can you give three examples? /be I found the documentation hard to follow since it assumes background I don't have and the examples were not interesting to me, but once I tried it I was pleasantly surprised. It does have ergonomic issues, an undefined and resolved promise work equally well, but I think this may be inexperience on my part. jjb ___ 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: yield and Promises
Hi Kris,
Your proposal has a lot of similarities to
http://wiki.ecmascript.org/doku.php?id=strawman:deferred_functions
which was proposed this past spring.
I'm not sure I follow what's top-down vs bottom-up about the two different
approaches. Let me suggest some terminology that has emerged in the proposal
process: I'll use generators to mean any single-frame, one-shot continuation
feature that's independent of the host event queue, and deferred functions to
mean any single-frame, one-shot continuation feature that is tied to the host
event queue by means of being automatically scheduled.
Generators directly solve a problem that is much less significant in normal
JS coding. While it is exciting that generators coupled with libraries give
us a much better tool for asynchronous use cases (the above can be coded with
libraryFunction(function*(){...}), my concern is that the majority use case
is the one that requires libraries rather than the minority case, and does
not promote interoperability.
It's true that generators require libraries in order to use them for writing
asynchronous code in direct style. And I agree with you and Alex and Arv that
there is a cost to not standardizing on those libraries. There are different
frameworks with similar but incompatible idioms for Deferred objects, Promises,
and the like, and they could be standardized.
A couple years later, I believe the landscape has dramatically changed, and
we indeed do have significant convergence on a promise API with the
thenable interface. From Dojo, to jQuery, to several server side libraries,
and apparently even Windows 8's JS APIs (from what I understand) all share an
intersection of APIs that include a then() method as a method to define a
promise and register a callback for when a promise is fulfilled (or fails).
This is an unusual level of convergence for a JS community that is so
diverse. I believe this gives evidence of well substantiated and tested
interface that can be used for top-controlled single-frame continuations that
can easily be specified, understood and used by developers.
But there's more to it than just the interface. You fix a particular scheduling
semantics when you put deferred functions into the language. I'm still learning
about the difference between the Deferred pattern and the Promises pattern, but
the former seems much more stateful than the latter: you enqueue another
listener onto an internal mutable queue. I'm not sure how much state can be
avoided with listeners (at the end of the day, callbacks have to be invoked in
some particular order), but that concerned me when I saw the deferred functions
proposal. I can't prove to you that that scheduling policy isn't the right one,
but I'm not ready to say it is.
So I'm not sure all scheduling policies are created equal. And with generators,
at least people have the freedom to try out different ones. I'm currently
trying one with task.js, and I hope others will try to come up with their own.
(There's also the added benefit that by writing the scheduler in JS, you can
instrument and build cool tools like record-and-reply debugging.)
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: yield and Promises
On Fri, Oct 21, 2011 at 9:41 AM, Brendan Eich bren...@mozilla.com wrote: On Oct 21, 2011, at 9:34 AM, John J Barton wrote: Can anyone summarize how these proposals relate to Kris Kowal / Kris Zyp / Mark Miller Q library: https://github.com/kriskowal/q Did you see https://github.com/kriskowal/q/tree/master/examples/async-generators yet? Thanks, I think that page clarifies my issue with generators: they solve a problem I don't have. See below. In my experience, reasoning about the code was much easier with Q than without Q. (Not something I found in trying generators). In order to say something that isn't subjective yet content-free other than negative, what was hard to reason about, and why? Can you give three examples? I only mentioned generators since Zyp's proposal uses yield. Now I'm regretting it because I really wanted to highlight Q. My comment is entirely subjective and intended to be positive about Q. The examples on the async-generators page cites above are clearer than the ones on the MDC generators page because they focus on next(). The strong case for generators is support for generic, encapsulated iteration. Examples illustrating this power would go a long way to build the case for them IMO. Examples of quirky iteration do not. Now back to Zyp's key point: using async functionality for iteration, powerful or not, does not address the key use-case for async. In particular, Q simplifies joining parallel async operations (XHR, postMessages, 'load', 'progress' events). Of course it may well be that generators provide an elegant solution to this important problem, but I've not seen such examples. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Protocol for new and instanceof?
On Fri, Oct 21, 2011 at 12:36 PM, Axel Rauschmayer a...@rauschma.de wrote:
In a vein similar to making [] available to collections, one could make
new and instanceof available to other inheritance schemes.
For example:
// “Meta-class” for prototypes as classes/instantiable prototypes
function ProtoExemplars() {}
ProtoExamplar.prototype.{
Has an official strawman been submitted for the extend operator? Having
trouble searching for it, but might be using the wrong terminology.
(Editorial: I love this operator)
operatorNew(...args) {
let inst = Object.create(this);
return inst.constructor(...args);
},
operatorInstanceof(lhs) {
return this.isPrototypeOf(lhs);
}
};
--
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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Protocol for new and instanceof?
Has an official strawman been submitted for the extend operator? Having trouble searching for it, but might be using the wrong terminology. (Editorial: I love this operator) Me, too (I also like the way it looks). http://wiki.ecmascript.org/doku.php?id=harmony:object_literals#set_literal_prototype_operator -- 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: yield and Promises
On Fri, Oct 21, 2011 at 10:20 AM, John J Barton johnjbar...@johnjbarton.com wrote: On Fri, Oct 21, 2011 at 9:41 AM, Brendan Eich bren...@mozilla.com wrote: On Oct 21, 2011, at 9:34 AM, John J Barton wrote: Can anyone summarize how these proposals relate to Kris Kowal / Kris Zyp / Mark Miller Q library: https://github.com/kriskowal/q In the credit where due dept., the original Q library is Tyler Close's ref_send library. Other related and prior work is linked to at http://wiki.ecmascript.org/doku.php?id=strawman:concurrency#see Did you see https://github.com/kriskowal/q/tree/master/examples/async-generators yet? Thanks, I think that page clarifies my issue with generators: they solve a problem I don't have. In that case, you might be equally uninterested ;) in http://wiki.ecmascript.org/doku.php?id=strawman:async_functions#reference_implementation which shows how to do the same thing with generators as proposed for ES-next. See below. In my experience, reasoning about the code was much easier with Q than without Q. (Not something I found in trying generators). In order to say something that isn't subjective yet content-free other than negative, what was hard to reason about, and why? Can you give three examples? I only mentioned generators since Zyp's proposal uses yield. Now I'm regretting it because I really wanted to highlight Q. My comment is entirely subjective and intended to be positive about Q. Thanks! I am positive about Q as well. And yes, I like Kris Kowal's implementation. The examples on the async-generators page cites above are clearer than the ones on the MDC generators page because they focus on next(). The strong case for generators is support for generic, encapsulated iteration. Examples illustrating this power would go a long way to build the case for them IMO. Examples of quirky iteration do not. Now back to Zyp's key point: using async functionality for iteration, powerful or not, does not address the key use-case for async. In particular, Q simplifies joining parallel async operations (XHR, postMessages, 'load', 'progress' events). Of course it may well be that generators provide an elegant solution to this important problem, but I've not seen such examples. Have you seen http://wiki.ecmascript.org/doku.php?id=strawman:concurrency#q.race and http://wiki.ecmascript.org/doku.php?id=strawman:concurrency#q.all ? If these don't address the joining you have in mind, could you post some examples? Thanks. jjb ___ 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: yield and Promises
On Oct 21, 2011, at 10:20 AM, John J Barton wrote: My comment is entirely subjective and intended to be positive about Q. We like Q too. :-) The examples on the async-generators page cites above are clearer than the ones on the MDC generators page because they focus on next(). The strong case for generators is support for generic, encapsulated iteration. Examples illustrating this power would go a long way to build the case for them IMO. Examples of quirky iteration do not. I agree, and thanks for the MDC comments -- I'll get some editing help deployed. Now back to Zyp's key point: using async functionality for iteration, powerful or not, does not address the key use-case for async. Not by itself. But to avoid rehashing, I'll stop here. In particular, Q simplifies joining parallel async operations (XHR, postMessages, 'load', 'progress' events). Of course it may well be that generators provide an elegant solution to this important problem, but I've not seen such examples. Not having to nest a callback and risk closure leaks (which Erik Corry nicely diagrammed in his JSConf.eu talk) is important. Please attend to this recurrent problem, about which I've been crystal clear. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Protocol for new and instanceof?
See http://wiki.ecmascript.org/doku.php?id=harmony:object_literals#object_extension_literal Sent from Samsung tabletAxel Rauschmayer a...@rauschma.de wrote: Has an official strawman been submitted for the extend operator? Having trouble searching for it, but might be using the wrong terminology. (Editorial: I love this operator) Me, too (I also like the way it looks). http://wiki.ecmascript.org/doku.php?id=harmony:object_literals#set_literal_prototype_operator -- 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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Protocol for new and instanceof?
On Fri, Oct 21, 2011 at 9:36 AM, Axel Rauschmayer a...@rauschma.de wrote:
In a vein similar to making [] available to collections, one could make
new and instanceof available to other inheritance schemes.
For example:
// “Meta-class” for prototypes as classes/instantiable prototypes
function ProtoExemplars() {}
ProtoExamplar.prototype.{
operatorNew(...args) {
let inst = Object.create(this);
return inst.constructor(...args);
},
operatorInstanceof(lhs) {
return this.isPrototypeOf(lhs);
}
};
More entirely unsubstantiated personal opinion based on a few days
experience:
Gonzala's https://github.com/Gozala/selfish does this now and with nicer
syntax.
One subtle point I missed about his approach: instance (member) variables
are created in initializers, not as literals, unless you intend to make the
variable part of a prototype. This could be stumbling block for Java
converts, who expect declarative members.
Only bump so far: XMLHttpRequest.apply fails and you can't run
XMLHttpRequest.prototype.addEventListener unless you run XMLHttpRequest() on
the object. So I could not figure out how to inherit from XMLHttpRequest.
jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Protocol for new and instanceof?
On Oct 21, 2011, at 11:49 AM, John J Barton wrote:
On Fri, Oct 21, 2011 at 9:36 AM, Axel Rauschmayer a...@rauschma.de wrote:
In a vein similar to making [] available to collections, one could make new
and instanceof available to other inheritance schemes.
For example:
// “Meta-class” for prototypes as classes/instantiable prototypes
function ProtoExemplars() {}
ProtoExamplar.prototype.{
operatorNew(...args) {
let inst = Object.create(this);
return inst.constructor(...args);
},
operatorInstanceof(lhs) {
return this.isPrototypeOf(lhs);
}
};
More entirely unsubstantiated personal opinion based on a few days experience:
Gonzala's https://github.com/Gozala/selfish does this now and with nicer
syntax.
That is nice, but it seems to me Axel was aiming to make the new and instanceof
operators useful. If you don't care about those operators, Irakli's library is
great.
One subtle point I missed about his approach: instance (member) variables are
created in initializers, not as literals, unless you intend to make the
variable part of a prototype. This could be stumbling block for Java
converts, who expect declarative members.
Java-heads may expect new and instanceof too, for that matter.
y bump so far: XMLHttpRequest.apply fails and you can't run
XMLHttpRequest.prototype.addEventListener unless you run XMLHttpRequest() on
the object. So I could not figure out how to inherit from XMLHttpRequest.
This seems like an XHR bug. Mail public-script-coord?
/be___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Protocol for new and instanceof?
(sorry for limitations of terrible tablet mailer)
Also, in general this sort of well known private method name hook is much more
extensible than internal method as currently used in the es spec. They also
avoid the need to polute the Proxy API
Allen
Sent from Samsung tabletBrendan Eich bren...@mozilla.com wrote:On Oct 21,
2011, at 11:49 AM, John J Barton wrote:
On Fri, Oct 21, 2011 at 9:36 AM, Axel Rauschmayer a...@rauschma.de wrote:
In a vein similar to making [] available to collections, one could make new
and instanceof available to other inheritance schemes.
For example:
// “Meta-class” for prototypes as classes/instantiable prototypes
function ProtoExemplars() {}
ProtoExamplar.prototype.{
operatorNew(...args) {
let inst = Object.create(this);
return inst.constructor(...args);
},
operatorInstanceof(lhs) {
return this.isPrototypeOf(lhs);
}
};
More entirely unsubstantiated personal opinion based on a few days experience:
Gonzala's https://github.com/Gozala/selfish does this now and with nicer
syntax.
That is nice, but it seems to me Axel was aiming to make the new and instanceof
operators useful. If you don't care about those operators, Irakli's library is
great.
One subtle point I missed about his approach: instance (member) variables are
created in initializers, not as literals, unless you intend to make the
variable part of a prototype. This could be stumbling block for Java converts,
who expect declarative members.
Java-heads may expect new and instanceof too, for that matter.
y bump so far: XMLHttpRequest.apply fails and you can't run
XMLHttpRequest.prototype.addEventListener unless you run XMLHttpRequest() on
the object. So I could not figure out how to inherit from XMLHttpRequest.
This seems like an XHR bug. Mail public-script-coord?
/be___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: yield and Promises
On 21/10/2011, at 17:40, Eric Jacobs wrote:
Jorge,
Would it still be satisfying to you if instead of writing the call expression
like this:
try {
response = asyncFunction(request); //might suspend execution
}
catch (e) {
//whatever
}
//our code continues here
we needed to write it with an explicit annotation, like this:
response = yield asyncFunction(request); //might suspend execution
or perhaps this:
yield { response = asyncFunction(request); } //might suspend execution
or some other creative way of statically encoding the might suspend
execution condition into the syntax?
Yes, of course, it would be fine. Why ?
--
Jorge.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: yield and Promises
On 21/10/2011, at 21:23, Dean Landolt wrote:
On Fri, Oct 21, 2011 at 3:20 PM, Jorge jo...@jorgechamorro.com wrote:
On 21/10/2011, at 17:40, Eric Jacobs wrote:
Jorge,
Would it still be satisfying to you if instead of writing the call
expression like this:
try {
response = asyncFunction(request); //might suspend execution
}
catch (e) {
//whatever
}
//our code continues here
we needed to write it with an explicit annotation, like this:
response = yield asyncFunction(request); //might suspend execution
or perhaps this:
yield { response = asyncFunction(request); } //might suspend execution
or some other creative way of statically encoding the might suspend
execution condition into the syntax?
Yes, of course, it would be fine. Why ?
Because this is the fundamental difference between shallow and deep
continuations.
Yes, if we can write this:
try {
response = yield asyncFunction(request); //might suspend execution
}
catch (e) {
//whatever
}
and asyncFunction can suspend/resume then it's alright.
Why ?
--
Jorge.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: yield and Promises
Jorge wrote: or some other creative way of statically encoding the might suspend execution condition into the syntax? Yes, of course, it would be fine. Why ? Because this is the crux of the run-to-completion debate that we're immersed in. Right now, JS has run-to-completion, where completion is defined as the end of a method, or a yield statement. If the yield statement continues to be required for code paths which may transfer control to another context, then that won't change, and all the run-to-completion objections to coroutines disappear. IOW, there is no difference WRT run-to-completion between generator-yield and coroutine-yield. The catch is, of course, that all code which either can yield, or can call other functions which yield, must have the yield keyword there, to mark that run-to-completion invariants will end at that point. This seems like a very reasonable compromise to me. -Eric ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: new ECMA262 5.1 engine
Wow!
That is quite some work that you've done here. Implementing an ES5
interpreter and contributions to test262.
Well, congratulations and thank you !
David
Le 21/10/2011 07:17, Yusuke Suzuki a écrit :
I got reply from Mr. Fugate, used test262 commad-line runner for lv5,
got some bugs in engine (JSON quote process and RegExp escape had a
bug. now fixed). Thanks for this great test suite!
Now, some test262 test cases are failed, but these failures have reasons.
First I found test262 bugs. So I heard from Mr. Fugate that bugs can
be reported at http://bugs.ecmascript.org, then reported them.
https://bugs.ecmascript.org/show_bug.cgi?id=215 // misspelling
grammar, sorry...
https://bugs.ecmascript.org/show_bug.cgi?id=216
https://bugs.ecmascript.org/show_bug.cgi?id=217
https://bugs.ecmascript.org/show_bug.cgi?id=218
And, I tried to implement RegExp.prototype.compile, but ES5 and ES3
not defined its standard behavior and I thought compile method is
changing RegExp#source / #global / #ignoreCase / #multiline which
writable attribute are false and breaking ES5 PropertyDescriptor
system, so I created template, but not implemented it.
https://github.com/Constellation/iv/commit/7cbc22474ada389a3ac8ab5d3ad5df38bed8a583
And some test cases (about 20 cases?) expect the enumeration order of
Object properties. (not reported yet)
For example, chapter15/15.2/15.2.3/15.2.3.14/15.2.3.14-2-8 expects
Object.keys Array order.
But I didn't implement ordered properties because ES5 didn't specify it.
So some tests are sometimes failed (if order happened to be expected,
test cases are passed...)
And S15.10.2.13_A1_T16 is failed. But backreference in ClassEscape is
not accepted, and my engine recognize [¥12-¥14] as the range that is
from 12 to 14. Do you think about it?
I passively think that this regexp raises SyntaxError in ES5 scope.
ES5 allows engine to extend RegExp syntax, but extended behavior is
not ensured by ES5.
http://es5.github.com/#x15.10.2.19
But other tes262 test cases are passed!
result is this (python tools/packaging/test262.py --command
~/dev/iv/obj/lv5/lv5 --full-summary result)
https://gist.github.com/1303151
If you try to run it, you can build lv5
https://github.com/Constellation/iv/wiki/lv5
and run test cases
http://wiki.ecmascript.org/doku.php?id=test262:command
If you find bugs, I would appreciate it if you would report it.
Thanks.
On Fri, Oct 21, 2011 at 3:54 AM, Juriy Zaytsev kan...@gmail.com wrote:
How does it fair on test262? http://test262.ecmascript.org/
--
kangax
On Wed, Oct 19, 2011 at 6:26 AM, Yusuke Suzuki utatane@gmail.com
wrote:
Hello.
I wrote new ECMA262 5.1 full support engine iv / lv5 in C++.
This is highly inspired from JSC, V8 and SpiderMonkey. (especially JSC)
https://github.com/Constellation/iv
This aims at most precise engine to ECMA262 5.1 specification. (like
the great engine,)
I read ECMA262 and wanted precise engine to understand this spec, so I
created.
features,
all ECMA262 5.1th features
(strict mode, direct call / indirect call to eval,
PropertyDescriptor, early errors, Object.prototype.toString.call(null
/ undefined), Object extras, Array extras, etc.)
BESEN// for example, directive prologure including octal value and
strict directive is rejected.
function test() { ¥02; use strict; }
stack VM
JSC like bytecode based PIC
ES5 oriented structures in C++ (PropertyDescriptor,
Attributes(Enumerable, Writable, Configurable))
optimized JSArray (using vector and hash map)
but this array implements full features of ECMA262 5.1th. for example,
var ary = [0, 1];
Object.defineProperty(ary, 'length', { writable : false });
ary.length = 4; // of cource, in strict mode, this raises error.
print(ary.length); // 2
try {
ary.push(2); // throw TypeError, because [DefineOwnProperty]
with throw = true is called.
} catch (e) {
print(e);
}
ary[3] = 2; // of cource ...
print(ary.length); // 2;
minimum source code
2 engines, VM and AST Interpreter. we can switch it by command line
option.
bytecode based backtrack RegExp (read re1 report and source code to
study VM based RegExp runtime, and implemented it)
ES5 oriented optimization
for example,
if I get eval keyword in strict mode, don't make variable
dynamic (hold on heap variable with offset access)
because direct call to eval in strict mode cannot create new
variable in upper local call site environment.
At first, I created AST Interpreter (named teleporter) which
algorithm is just the same to ECMA262 specification.
And after it is done, I created optimized bytecode VM (named railgun).
These 2 engines are abstracted, so we can switch it at runtime.
('--interp option')
AST Interpreter is very slow, but this source code is exactly the same
to ECMA262 specification algorithm, so this may be interesting for
spec readers.
And,
Re: new ECMA262 5.1 engine
On Oct 20, 2011, at 10:17 PM, Yusuke Suzuki wrote: And, I tried to implement RegExp.prototype.compile, but ES5 and ES3 not defined its standard behavior and I thought compile method is changing RegExp#source / #global / #ignoreCase / #multiline which writable attribute are false and breaking ES5 PropertyDescriptor system, so I created template, but not implemented it. https://github.com/Constellation/iv/commit/7cbc22474ada389a3ac8ab5d3ad5df38bed8a583 see http://wiki.ecmascript.org/doku.php?id=harmony:regexp_match_web_reality ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: yield and Promises
On Oct 21, 2011, at 12:49 PM, Eric Jacobs wrote: The catch is, of course, that all code which either can yield, or can call other functions which yield, must have the yield keyword there, to mark that run-to-completion invariants will end at that point. This seems like a very reasonable compromise to me. If you have to yield at every point in a call chain that might reach a coroutine that captures a deep continuation, then you've really got a chain of shallow continuations. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: yield and Promises
On Fri, Oct 21, 2011 at 10:46 AM, Mark S. Miller erig...@google.com wrote: On Fri, Oct 21, 2011 at 10:20 AM, John J Barton johnjbar...@johnjbarton.com wrote: In particular, Q simplifies joining parallel async operations (XHR, postMessages, 'load', 'progress' events). Of course it may well be that generators provide an elegant solution to this important problem, but I've not seen such examples. Have you seen http://wiki.ecmascript.org/doku.php?id=strawman:concurrency#q.race and http://wiki.ecmascript.org/doku.php?id=strawman:concurrency#q.all ? If these don't address the joining you have in mind, could you post some examples? Thanks. Unfortunately I was not able to follow the comments on that page. (These strawman pages are hard to follow because they describe new things using new terminology). This code seems to do what I intended: https://github.com/johnjbarton/Purple/blob/master/chrome/extension/pea.js#L114 The structure is: start A, start B, when AB (start C, start D, when CD (we win))); The code marches right but for me the key is being able to predict the relative order of the calls. Of course this particular example is not good for comparing different alternatives. I guess the biggest win for Q comes in unconventional cases where async is used for remote communications and such examples are currently complex. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: yield and Promises
Brendan Eich wrote: On Oct 21, 2011, at 12:49 PM, Eric Jacobs wrote: The catch is, of course, that all code which either can yield, or can call other functions which yield, must have the yield keyword there, to mark that run-to-completion invariants will end at that point. This seems like a very reasonable compromise to me. If you have to yield at every point in a call chain that might reach a coroutine that captures a deep continuation, then you've really got a chain of shallow continuations. /be As a language end-user, I'm not sure that I would (or should) be concerned about the distinction between a deep continuation and a chain of shallow continuations. After all, the stack is just a chain of frames, and the mechanism by which those frames are chained together is not of semantic importance to the language. That said, coroutinish features like having stacktraces that show multiple levels of blocking operations, and try/catch blocks that can catch over several blocking operations would be really nice to have. If those features can be built at the library level using shallow continuations or generator trampolines or what have you, I say great. -Eric ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: yield and Promises
On Oct 21, 2011, at 2:03 PM, Eric Jacobs wrote: As a language end-user, I'm not sure that I would (or should) be concerned about the distinction between a deep continuation and a chain of shallow continuations. After all, the stack is just a chain of frames, and the mechanism by which those frames are chained together is not of semantic importance to the language. My point was simply that it ain't coroutines or deep continuations if you are required to say yield at each frame. That said, coroutinish features like having stacktraces that show multiple levels of blocking operations, and try/catch blocks that can catch over several blocking operations would be really nice to have. If those features can be built at the library level using shallow continuations or generator trampolines or what have you, I say great. That's the plan. Deep continuations are out for the two reasons (implementor diversity vs. interop, run-to-completion auditability) I gave. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Protocol for new and instanceof?
As for xmlhttprequest not working, I get DOM object constructor cannot be called as a function This basically means xmlhttprequest is a host object which does not want to behave normally. Maybe with some very subtle tricks you can get it to subclass but I recommend not subclassing host objects. I also have a feeling axel means defining a meta object with behaviour for instanceof and new then having every other class-like object inherit it as a base class. As an aside if we allow overloading of new and instanceof, can we overload every operator? On Oct 21, 2011 7:49 PM, John J Barton johnjbar...@johnjbarton.com wrote: On Fri, Oct 21, 2011 at 9:36 AM, Axel Rauschmayer a...@rauschma.de wrote: In a vein similar to... More entirely unsubstantiated personal opinion based on a few days experience: Gonzala's https://github.com/Gozala/selfish does this now and with nicer syntax. One subtle point I missed about his approach: instance (member) variables are created in initializers, not as literals, unless you intend to make the variable part of a prototype. This could be stumbling block for Java converts, who expect declarative members. Only bump so far: XMLHttpRequest.apply fails and you can't run XMLHttpRequest.prototype.addEventListener unless you run XMLHttpRequest() on the object. So I could not figure out how to inherit from XMLHttpRequest. jjb ___ 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: Protocol for new and instanceof?
Also, in general this sort of well known private method name hook is much more extensible than internal method as currently used in the es spec. They also avoid the need to polute the Proxy API Reified names (private or otherwise) are a very powerful mechanism. I’m not aware of another programming language that does this (possibly Common Lisp with its symbols, but I don’t know enough about them). It’s good to have them, because they increase JavaScript’s expressiveness. -- 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: Protocol for new and instanceof?
On Fri, Oct 21, 2011 at 7:08 PM, Axel Rauschmayer a...@rauschma.de wrote: Also, in general this sort of well known private method name hook is much more extensible than internal method as currently used in the es spec. They also avoid the need to polute the Proxy API Reified names (private or otherwise) are a very powerful mechanism. I’m not aware of another programming language that does this (possibly Common Lisp with its symbols, but I don’t know enough about them). It’s good to have them, because they increase JavaScript’s expressiveness. Private names in basically the same form as have been accepted for ES.next are available in Racket [1], with the equivalent of the 'private x;' syntax that we proposed but didn't make the cut. I believe that the system in Racket was one of the inspirations for Dave's original private name proposal long long ago. [1] http://pre.racket-lang.org/docs/html/reference/createclass.html?q=define-local#%28form._%28%28lib._racket/private/class-internal..rkt%29._define-local-member-name%29%29 -- sam th sa...@ccs.neu.edu ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Protocol for new and instanceof?
Private names in basically the same form as have been accepted for ES.next are available in Racket [1], with the equivalent of the 'private x;' syntax that we proposed but didn't make the cut. I believe that the system in Racket was one of the inspirations for Dave's original private name proposal long long ago. [1] http://pre.racket-lang.org/docs/html/reference/createclass.html?q=define-local#%28form._%28%28lib._racket/private/class-internal..rkt%29._define-local-member-name%29%29 -- sam th sa...@ccs.neu.edu also see Smalltalk selector namespaces http://www.smalltalksystems.com/publications/subsys.pdf which have also been proposed for Ruby http://www.sapphire-lang.org/wiki/1/Selector_namespaces Because Smalltalk selectors selectors (ie, names) can operationally be any object, sometimes newly instantiated objects are used when a guaranteed unique method selector is needed for system purposes. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: yield and Promises
On 10/21/2011 11:01 AM, David Herman wrote:
[snip]
But there's more to it than just the interface. You fix a particular
scheduling semantics when you put deferred functions into the
language. I'm still learning about the difference between the Deferred
pattern and the Promises pattern, but the former seems much more
stateful than the latter: you enqueue another listener onto an
internal mutable queue.
At least in the Dojo community (and I think Kowal does with Q as well),
we define a Deferred producer-sider constructor for creating promises,
with an API that can resolve() or reject() the generated promise. The
promise is then the consumer-side interface that allows consumer to
register a callback for the fulfillment or rejection of the promise
(with a then() method or a variety of other convenience functions). The
mutable state pattern was used in earlier versions of Dojo, but later we
switched to an API that keeps promises immutable except for legacy
methods, as we have reached consensus that mutable promises are bad.
Thus the terminology difference between mutable state and immutable
state is simply wrong vs right for us ;).
There are indeed different scheduling semantics to consider. With Dojo
(and I think jQuery as well), we have considered enqueuing callbacks
onto the event queue to unviable because historically the only mechanism
within the browser has been setTimeout (there is no setImmediate or
process.nextTick available) which has a rather large minimum delay that
can easily up add to noticeable and unacceptable introduction of delays
with a chain of a series of promises. Consequently our implementations
do not enqueue any callbacks for future turns, all callbacks are
executed in the same turn as the resolution of the promise, and due to
latency concerns we haven't really felt the freedom to explore other
scheduling semantics. This scheduling semantic has worked fine for us,
but I don't mind an alternate one. It looks like kriskowal/q does
enqueue, using a postMessage hack to enable faster enqueuing on newer
browsers.
On 10/21/2011 10:34 AM, John J Barton wrote:
Can anyone summarize how these proposals relate to Kris Kowal / Kris
Zyp / Mark Miller Q library:
https://github.com/kriskowal/q
The proposal was designed such that it should work smoothly with Kowal's
Q originating promises as well (acting like Q.when). For example, using
the opening example of delay function from the kriskowal/q readme, one
could write:
function(){
return afterOneSecond(yield delay(1000));
}
and it would be effectively the same as (with the possible exception of
scheduling policies):
function(){
return Q.when(delay(1000), afterOneSecond);
}
In my experience, reasoning about the code was much easier with Q than
without Q. (Not something I found in trying generators). I found the
documentation hard to follow since it assumes background I don't have
and the examples were not interesting to me, but once I tried it I was
pleasantly surprised. It does have ergonomic issues, an undefined and
resolved promise work equally well, but I think this may be
inexperience on my part.
Yes, kriskowal/q is an excellent library.
Thanks,
Kris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Protocol for new and instanceof?
Thanks! Nothing surprises me about Racket. Maybe when it *doesn’t* have a feature. ;-) On Oct 22, 2011, at 1:13 , Sam Tobin-Hochstadt wrote: On Fri, Oct 21, 2011 at 7:08 PM, Axel Rauschmayer a...@rauschma.de wrote: Also, in general this sort of well known private method name hook is much more extensible than internal method as currently used in the es spec. They also avoid the need to polute the Proxy API Reified names (private or otherwise) are a very powerful mechanism. I’m not aware of another programming language that does this (possibly Common Lisp with its symbols, but I don’t know enough about them). It’s good to have them, because they increase JavaScript’s expressiveness. Private names in basically the same form as have been accepted for ES.next are available in Racket [1], with the equivalent of the 'private x;' syntax that we proposed but didn't make the cut. I believe that the system in Racket was one of the inspirations for Dave's original private name proposal long long ago. [1] http://pre.racket-lang.org/docs/html/reference/createclass.html?q=define-local#%28form._%28%28lib._racket/private/class-internal..rkt%29._define-local-member-name%29%29 -- sam th sa...@ccs.neu.edu -- 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: Protocol for new and instanceof?
On Oct 22, 2011, at 2:18 , Allen Wirfs-Brock wrote: also see Smalltalk selector namespaces http://www.smalltalksystems.com/publications/subsys.pdf which have also been proposed for Ruby http://www.sapphire-lang.org/wiki/1/Selector_namespaces Because Smalltalk selectors selectors (ie, names) can operationally be any object, sometimes newly instantiated objects are used when a guaranteed unique method selector is needed for system purposes. Very interesting, thanks! I find that concepts in my code are fairly stable, but their names aren’t. Completely separating the concerns of identifying a concept and naming a concept might make sense in large systems. But it obviously makes it more difficult to edit source code (no more vi...). -- 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
