revisiting "shift"

Peter van der Zee ecma at qfox.nl
Wed Apr 28 11:33:10 PDT 2010


> I don't understand this question-- do you mean whatever value the
> handler function (in the example, function(k) { return k })
> returns? Then no, there's no augmentation or mutation here. The
> continuation is represented as an object with three methods:

Ah, I didn't know that.

>> It'd be cleaner if it was just shift()
>>
> You might think so, since the semantics seems simpler-- but it
> would lead to uglier programs. You're not affording the writer of
> the function doing the shift any ability to specify what to do
> after the shift, and you're not giving them the ability to
> communicate any data to the caller. This requires them to
> coordinate with clients to save any additional action in some side-
> channel, e.g.:
>
> // library
> function gen(thenWhat) {
> ...
> thenWhat.action = function() { ... /* do more stuff */ ... }; let
> received = shift(); ... }
>
> // client
> var k = gen({ action: function() { } });

Hm. Maybe you meant to return the function to allow access to the local variable 
k through a closure? And not a fingerprint 
mixed shift(function)
as I read it at first? In that case sure, fine :)

The shift could also expose the iterated value in the continuation object as a 
read-only property (or getter). The shift itself would return whatever you give 
.send as parameters. But maybe this was what you meant in the first place..

Whatever needs to be done before or after the shift should obviously be done 
from within the loop. I see no problems with that myself, but maybe I'm missing 
something?

>> But maybe I'm knifing an entire API here I don't know about :)
>> Otherwise the send method seems redundant.
>>
> I'm not sure what the send method has to do with it-- it sounds

That would be the API I didn't know about ;)

On a sidenote; continuations could be implemented much like timers are now. I 
mean, for timers to work, you would already have to have a way to preserve state 
and stack because you have to access it when the timer fires. This proposal 
could just extend the API using the same mechanics as the timers (I read 
something about this proposal being a possible problem for vendors). But rather 
than being executed when some time has elapsed, the callback would be fired on 
demand. After implementing setTimeout and setInterval, this should be quite 
easy...

I also read syntax using try{}catch(){} as some kind of "continue" mechanism and 
just wanted to say I find it really ugly and hackish. I've not seen any 
arguments that justify introducing such a mechanism (but it might not be part of 
this proposal, I'm sorry and happy if it wasn't :)).

- peter



More information about the es-discuss mailing list