> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
