revisiting "shift"

Peter van der Zee ecma at qfox.nl
Thu Apr 29 00:03:38 PDT 2010


On Thu, Apr 29, 2010 at 2:21 AM, David Herman <dherman at mozilla.com> wrote:

> > 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.
>
> Dave
>
>
Reading your original post again, more thoroughly this time, it becomes
clear to me that I've misinterpreted it. And you indeed stated the send,
throw, close "api" there.

I still believe that the callback is redundant, but for now I'll just shut
up.

As for the try/catch statement, I was confused with the Iterators and the
way they were implemented in JS 1.7. You used try/catch in one example and
that's how I got confused.

- peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100429/4daf8755/attachment.html>


More information about the es-discuss mailing list