revisiting "shift"

David Herman dherman at
Wed Apr 28 17:21:40 PDT 2010

> 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?

I don't know what you're saying, but I have already posted the semantics in this thread. I *think* it should be pretty clear. (If others are confused about it, please do weigh in.)

> 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..

If I understand this, it still doesn't give the function that does the shift very much room to do anything interesting after it pops the function activation.

> 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?

I think you are. When the shift happens, it pops the activation frame, which means that the rest of the function after the shift stops running. This is what a continuation operator is all about-- suspending control and saving it in a value that can be called later. The purpose of calling the handler function is to do something *immediately* after popping the activation frame, not later when the activation is resumed.

> 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...

None of this is true. Closures are not the same thing as continuations.

That said, if this is a hardship for implementers, I'd be interested in having them weigh in.

> 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'm genuinely baffled by this comment.


More information about the es-discuss mailing list