On Dec 9, 2010, at 3:27 PM, David Herman wrote:
>> I'm not trying to open the can-o'-worms around block level changes. The
>> above code suggests that a 'yield' suspension of execution is local to the
>> nearest container { } block, in this case the try { } block.
>
> No, that's not the case. T
> I'm not trying to open the can-o'-worms around block level changes. The above
> code suggests that a 'yield' suspension of execution is local to the nearest
> container { } block, in this case the try { } block.
No, that's not the case. That code was not hypothetical: it works in
SpiderMonkey
On Thu, Dec 9, 2010 at 12:22 PM, Getify Solutions wrote:
> 1. I'm not trying to open the can-o'-worms around block level changes. The
> above code suggests that a 'yield' suspension of execution is local to the
> nearest container { } block, in this case the try { } block
No, as implemented in JS
>
> This reminds me of a proposal by Kris Zyp a couple of months ago
> ("single frame continuations")
> https://mail.mozilla.org/pipermail/es-discuss/2010-March/010865.html
>
> I don't think that discussion lead to a clear outcome, but it's definitely
> related, both in terms of goals as well
On Wed, 08 Dec 2010 21:43:06 +0100, Gavin Barraclough
wrote:
According to the ES5 spec a regular expression such as /[\w-_]/ should
generate a syntax error. Unfortunately there appears to be a
significant quantity of existing code that will break if this behavior
is implemented (I have
>
> var task = new Task(function() {
> var request = new HttpRequest();
> try {
> var foo = yield request.send(this, "foo.json");
> var bar = yield request.send(this, "bar.json");
> var baz = yield request.send(this, "baz.json");
> }
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The generators from JS 1.7 are too specific to provide much help with
promises, IMO. Adding a yield operator fundamentally alters the
semantics of the entire surrounding function, violating the principle
of locality. Consequently you need special mec
It might surprise some who know me to hear this, but I agree with Dave
on this. There's a huge gap between the single-frame mechanism and
going the whole hog. Going all out does buy you some expressive
power, but at the cost of complicating everything. If the simple
mechanism gives you most of w
PS To be concrete, here's an example code snippet using my jstask library that
chains several event-generated actions together in a natural way (i.e., in
direct style, i.e. not in CPS):
var task = new Task(function() {
var request = new HttpRequest();
try {
var fo
I pretty much abandoned that line of investigation with the conclusion that
generators:
http://wiki.ecmascript.org/doku.php?id=strawman:generators
are a good (and well-tested, in Python and SpiderMonkey) design for
single-frame continuations. They hang together well; in particular, they don
10 matches
Mail list logo
