natively negotiating sync vs. async...without callbacks

Breton Slivka zen at
Tue Dec 7 17:19:16 PST 2010

On Wed, Dec 8, 2010 at 8:48 AM, Getify Solutions <getify at> wrote:

> I am aware that I'm kicking a potentially angry beehive by bringing up this
> topic, but I wanted to just have some discussion around if there's any
> possibility that JavaScript can, in the near term, have a native mechanism
> added to it for better managing of sync vs. async coding patterns, without
> nested callbacks.

> Briefly, in summary, I'm suggesting a statement like this in JavaScript:
> ????   X(1,2)    ????    Y(3,4)    ????    Z("foo")    ????;
> `X`, `Y`, and `Z` are all possibly function calls which will not complete
> synchronously, but may defer their fulfillment asynchronously until a later
> time/event.
> The spirit of the proposal is that this special type of statement be a
> linear sequence of function executions (as opposed to nested
> function-reference callbacks delegating execution to other code).
> The special behavior is that in between each part/expression of the
> statement, evaluation of the statement itself (NOT the rest of the program)
> may be "suspended" until the previous part/expression is fulfilled. This
> would conceptually be like a yield/continuation localized to ONLY the
> statement in question, not affecting the linear execution of the rest of the
> program.
> _______________________________________________
> es-discuss mailing list
> es-discuss at
I haven't found anyone else that has worked this out, and I have been
keeping it kind of a secret, but seeing as I haven't yet done anything with
it, I will reveal that what you propose is more or less possible with plain
vanilla ecmascript 3.  To modify your syntax proposal, what the syntax would
look like is something like this:


this call returns an object, with a call, and an apply method (possibly a
function object?) that when called, starts a chain of execution that is
suspended at the finishing of each operand. Most of the time this suspension
would be caused by a simple call to setTimeOut(next, 0); With other
functions that are obviously asyncronous, such as XHR calls, the suspension
is resumed at the point when the callback would normally be called.

This would be made possible by a library, I will call MND for the purposes
of this discussion.  You start by passing MND an object with a set of
related methods:

   var MyMonad = MND.make(MyObject);

the MyMonad object has methods with all the same names as the object that
you passed in, but when you call them, the names and arguments are simply
placed on an internal stack, and an object with call/apply methods is

When the call function is invoked, it loops through the version of the stack
stored on that particular object, by executing each method in turn, and in
the spot where each method requires a callback, it places an additional
helper function to continue execution of the stack. Additionally, the return
value of the previous method call is passed in a parameter (perhaps as a
property of "this") to the next function to be executed. The initial
function call (above, as $(document)), allows you to pass in some starting
value for this chain of execution.

The only drawback is that the call/apply method would itself require a
callback function, for when the whole chain finishes, but that is still far
preferable than multiply nested callbacks, which is, I presume, the problem
you are attempting to solve.

I think the syntax for this type of library is simple enough to not require
new syntax. In fact it's pretty similar to jQuery, which as you probably
know is quite popular specifically for its simplicity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list