natively negotiating sync vs. async...without callbacks

[Bradley Meck]

I really like the proposal, but think the syntax is confusing many of us.

I think that the proposal is closer to post hooking than continuation in
spirit. It appears that the syntax is misleading but reading the text of the
desired effects promise.defer() is acting like a point to hook the next part
of the expression rather than a yield (not sure if it would make more sense
to make this construct in whatever syntax return from the current function).
The reason that I believe this is the case is the fact that the stack is
unwound / "normal" closure abnormalities apply it seems. The interesting
part of this proposal is the fact that you can pass messages between hooks
to me. Overall, I find a hooking proposal to be beneficial since soo many
times I am making anonymous functions to do so. Having to declare a hooking
point might be overkill, but the message passing and a generic code pathing
on error would be amazing for async dev time personally.

I think given the side effects wanted these are the list of features in this
proposal:

1. code run in this "statement" does so at the first opportune moment (sync
runs immediately)
2. code in this statement does not start execution until some condition is
true
3. code that encounters and error in this statement is routed to a construct
in this statement automatically.

Given these I propose a different syntax, since #2 is the main issue with
why it is being considered similar to a continuation. I think that this
construct should declare up front instead of inline when it defers. This
syntax is still poor but should help to illustrate (using a binary ! since
js doesnt have one).

foo = function(cb) { setTimeout(cb,1000) }
bar = function(cb) { ... cb(1) ... }
end = function(cb,x) { log(x) } // will log 1
foo @ bar @ end ! err

Would mean that foo should wait until cb is fired in defer. Then if it does
not error it would go to bar and pass along some context arguments. If it
errors it would go to err. If bar does not error it would go to end. If bar
errors it would go to err still.

So how does this relate to making things easier?

1. Error routing callbacks. This would be a god send if you have ever used
node.js .
2. No confusing continuations (many people like them but I find them hard to
track code wise).
3. Passing data between callbacks would not require a closure construction
which is generally costly.
4. What is being defered on does not break functions since it is an argument
automatically passed (non-ideal since it could cause issues with existing
code). Like Kyle proposed a keyword maybe needed etc.

Cheers,
Bradley

On Thu, Dec 9, 2010 at 9:09 PM, Brendan Eich <brendan at mozilla.com> wrote:

> On Dec 9, 2010, at 3:27 PM, David Herman wrote:
>
> >> I'm not trying to open the can-o'-worms around block level changes. The
> above code suggests that a 'yield' suspension of execution is local to the
> nearest container { } block, in this case the try { } block.
> >
> > No, that's not the case. That code was not hypothetical: it works in
> SpiderMonkey using extensions that have been around for several years.
>
> Works in Rhino too, thanks to Norris Boyd, Steve Yegge, et al.
>
> /be
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20101210/bc418585/attachment.html>