-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 4/1/2010 9:45 AM, Dave Herman wrote:
>> I am not exactly sure what that intent is here, but I am guessing it
>> is supposed to flash several times before showing the alert.
>
> No, sorry that I meant window.setInterval rather than
window.setTimeout, but otherwise I think I wrote what I meant. I wanted
it to alert "done setup!" immediately after installing the animation,
not after the animation finishes. Similarly, I wanted setFlashing to add
itself to an array immediately after setting up the animation. Don't
worry about only doing it 10 times, just let it flash forever. :)
In order to utilize leverage continuations with a function that
execute multiple we would need to eliminate single-shot restriction.
You could then create some library function that passed the
continuation to the setInterval function to do something like:
var toggle = true;
intervalling->(INTERVAL);
elt.style.background =...
But in this case, using the yielding call would be confusing and
provide very little benefit. This is definitely not the type of
scenario that it is designed for, normal anon functions work great
here. This is geared for when a callback is used to execute the
remainder of a sequence after the completion of an asynchronous that
we see so often in JavaScript.
>
>> This really lead me to think about if it would be possible to meet
>> the
>> goals of this proposal *and* make this fully compatible (syntax and
>> default behavior) with JS 1.7 generators. That is make it compatible
>> with generators and still making it sufficiently extensible to meet
>> the broad range of needs that could utilize single-frame
>> continuations/coroutines. And I believe it is, and it could done in a
>> way that this proposal could be implemented in JavaScript as well
>> generators. Do you think it would be worth exploring that
>> possibility?
>
> I actually have already sketched such a translation, albeit using the
semantics I proposed. I'm including it below. Essentially, you have to
translate *two* things: 1) the `yield' expression form, and 2) generator
functions. The latter is necessary because generator functions don't
start executing their function body until the first `send'. So the
translation is:
>
> yield <expr> ~~> this.receive(this->yield(<expr>))
>
> and
>
> function f(x1, ..., xn) body ~~>
> function f(x1, ..., xn) {
> return new Generator(function () {
> (function f(x1, ..., xn) body).call(this, x1, ..., xn);
> });
> }
>
> Actually, I think this probably gets `this' wrong; I don't have the
time ATM to look up what the semantics of `this' is within a generator
body. But that should be pretty easily fixable.
>
> At any rate, this is relatively clean and I think's a plausibility
check that single-frame continuations should be simpler and more general
than generators, and likely compatible with them.
Yes, I believe that should work.
Do you prefer basing single-frame continuations on new non-latin
character syntax instead of using the "yield" keyword (hadn't realized
it was already reserved in ES5 strict-mode when I did the first proposal)?
- --
Kris Zyp
SitePen
(503) 806-1841
http://sitepen.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAku5UaIACgkQ9VpNnHc4zAz+WgCdFP+IO+vsvD+px3vPur90sSS/
3noAnR6TeYw+Q18IEB7BAXmQMPw8klVj
=Ydpt
-----END PGP SIGNATURE-----
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
