search

ericmckean / traceur-compiler

Automatically exported from code.google.com/p/traceur-compiler
Apache License 2.0
0 stars 0 forks source link

yield semantics (and syntax have change considerably) #93

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
The page http://wiki.ecmascript.org/doku.php?id=harmony:generators shows the 
syntax for the yield keyword.  It should be possible to use it in a method 
which returns a value, e.g.

```javascript

function buf(){
  var x;
  while (true){
    x = yield x;
  }
}
var b = buf();
b.next();
var n = b.send(10);//n = 10
n = b.send(20);//n = 20

One of the key use cases is the ease with which we can use this to replace the await keyword by simply wrapping our function in something like the Q promises library (https://github.com/kriskowal/q) which provides the (experimental) method Q.async to take a function which uses yield to await promises and returns a new function which produces promises. This currently works amazingly well in Firefox.


Original issue reported on code.google.com by `Forbes.Lindesay` on 1 May 2012 at 1:30
GoogleCodeExporter commented 9 years ago 
Generators and iterators is on my list to fix. There is one big contention here 
though. SpiderMonkey is shipping generators and iterators based on exceptions 
and TC39 has raised concerns to base this on exceptions. Personally I don't 
care but I want this to be settled before I start making changes to the 
generators.

Original comment by arv@chromium.org on 1 May 2012 at 6:04

GoogleCodeExporter commented 9 years ago 
Has there been any progress on this?

Original comment by Forbes.Lindesay on 8 Aug 2012 at 5:53

GoogleCodeExporter commented 9 years ago 
I would still like the issue in comment 1 to be resolved before investing time 
on this.

Original comment by arv@chromium.org on 8 Aug 2012 at 7:04

GoogleCodeExporter commented 9 years ago 
Since it's currently only when the iterator generator exits that anything 
happens based on exceptions, could we not implement everything else and then 
resolve that behaviour at the end.  Alternatively, could traceur not be used as 
a platform for experimenting if TC39 have anything else in mind.  Has any 
progress on the issue of generators been made in the last 3 months?  Is there a 
way to help TC39 move towards a speedy decision about how returning should be 
dealt with.

Original comment by Forbes.Lindesay on 8 Aug 2012 at 8:08

GoogleCodeExporter commented 9 years ago 
It is possible to do the work needed without changing to an exception based 
iteration protocol.

Original comment by arv@chromium.org on 8 Aug 2012 at 9:04

GoogleCodeExporter commented 9 years ago 
In that case, what's your concern about doing the work?

Original comment by Forbes.Lindesay on 9 Aug 2012 at 9:53

GoogleCodeExporter commented 9 years ago 
This is a large change and I don't have enough time to look at this any time 
soon.

Currently we only support yield as a statement. We need to support yield 
expressions. To do that we need to rewrite expressions that contains yield 
which is a pretty large task given how many different expression forms there 
are. For example

E1 op yield E2

=>

$tmp1 = E1;
$tmp2 = yield E2  // special form that is the leaf
$tmp3 = $tmp1 op $tmp2

Original comment by arv@chromium.org on 9 Aug 2012 at 7:06

GoogleCodeExporter commented 9 years ago 
In that case, would it be possible to move this forward if I help by 
contributing some time.  If we can agree a broad framework for how this should 
be done, I'm happy to spend a little time now and then implementing and testing 
additional expressions.

Original comment by Forbes.Lindesay on 9 Aug 2012 at 9:13

GoogleCodeExporter commented 9 years ago 
That would be awesome.

There are some clear stages towards getting this done.

1. Update the parser and validator to support yield expressions
2. Figure out how to break all expressions into the parts that depends on yield 
into unique states.
3. Either update the generator transformer to understand these states or do 
this transformation in a separate step before the current transformation (I 
would prefer that it was done in the same step).

I think the first step is to understand CPSTransformer.js to see how something 
simple like transformBlock works.

Sorry for hand waving, I don't know how the CPS transformer fully works.

Original comment by arv@chromium.org on 9 Aug 2012 at 9:36

GoogleCodeExporter commented 9 years ago 
I have been experimenting a little with using "await" and have found it to be 
rather disappointing.
The trouble is a function, for example "do_a_sequence_of_asynchronous_requests" 
that has a lot of uses of "await" in its body cannot itself be used as a 
function that can be called with "await" -- because this function must return a 
Deferred, and a function which calls "await" cannot return a value at all!

(or can it, is there a way to do this?

Original comment by kgra...@gmail.com on 27 Sep 2012 at 9:13

GoogleCodeExporter commented 9 years ago 
kgrael: You are correct. Same thing applies to yield. It would be bad if any 
function call could just pause the execution. The general rule is that you have 
some kind of runner. In the demo at, 
http://code.google.com/p/traceur-compiler/source/browse/demo/await.html, the 
deferred is fulfilled by the callback to setTimeout.

Also, see http://taskjs.org/ for one such runner.

Original comment by arv@chromium.org on 27 Sep 2012 at 9:26

GoogleCodeExporter commented 9 years ago 
I am accustomed to having the ability to compose functions that make use of 
yielding. I wrote an example gist of how it can be done using the "tornado" web 
framework in Python.

https://gist.github.com/3796677

Will moving from "await" to "yield" give me the ability to compose such 
functions?

Original comment by kgra...@gmail.com on 27 Sep 2012 at 9:58

GoogleCodeExporter commented 9 years ago 
https://code.google.com/p/traceur-compiler/source/detail?r=a6f23cf2f88fb085b26f0
21204c58c556b67221b

Original comment by arv@chromium.org on 13 Nov 2012 at 3:13

GoogleCodeExporter commented 9 years ago 
https://code.google.com/p/traceur-compiler/source/detail?r=a0a8684f36f4903f03829
b83a7ac7949ab9743fa

Original comment by arv@chromium.org on 15 Nov 2012 at 2:55

GoogleCodeExporter commented 9 years ago 
https://code.google.com/p/traceur-compiler/source/detail?r=f4a964e62197a8e1286e5
b0ca94abb513d7088bc

Original comment by arv@chromium.org on 15 Nov 2012 at 2:58

GoogleCodeExporter commented 9 years ago 
Issue 178 has been merged into this issue.

Original comment by arv@chromium.org on 7 Dec 2012 at 8:17

GoogleCodeExporter commented 9 years ago 
Issue 178 has been merged into this issue.

Original comment by arv@chromium.org on 7 Dec 2012 at 8:37

GoogleCodeExporter commented 9 years ago 
Issue 183 has been merged into this issue.

Original comment by arv@chromium.org on 14 Dec 2012 at 10:15