How about a "Q" language extension to JavaScript?

76 views
Skip to first unread message

Tom Robinson

unread,
May 7, 2012, 9:51:33 PM5/7/12
to q-con...@googlegroups.com
One idea I've toyed with is nicer syntax for promises. IMHO promises should be baked into the language.

That obviously won't happen in JavaScript itself any time soon, but could we bolt it on, as an optional language extension? What would that look like?

Just hoping to open a dialog at this point.

-tom

Kris Kowal

unread,
May 7, 2012, 10:06:25 PM5/7/12
to q-con...@googlegroups.com
Here’s Mark Miller’s proposal:

http://wiki.ecmascript.org/doku.php?id=strawman:concurrency

The proposal is to standardize a form of the Q library (which differs
in a few ways from my implementation, as detailed here
https://github.com/kriskowal/q/wiki/Comparing-ES-Harmony-Concurrency-Strawman)

Mark is conservatively asking for a "!" operator that would be an
"eventual" ".". For example, "a.b" gets "b" from "a" immediately, but
"a!b" gets a promise for "b" from "a", and "a" may be a promise
itself, or even a remote object. "!" is bought and sold anywhere "."
is accepted, from method invocation to deletion.

A more liberal proposal, as might be implemented with a to-javascript
compiler, would add keywords like "when" and "where".

var a = getPromise();
when (a) {
a.foo() // a is now fulfilled and replaces the eponymous promise
in this scope
} catch (exception) { // for eventual rejection
} finally {
// as usual
}


When blocks would be expressions.

var b = when(c) { c + 10 }


Where blocks would be relevant for RPC. The block of code would be
sent as a string to the remote and executed in hermetically sealed box
with direct access to that object. It would also support the same
catch and finally chain as try/when.

var c = where (d) { d.getTemperature() }

As opposed to the equivalent.

var c = d!getTemperature()


Most of these ideas were pretty thoroughly explored with E, so you
might look into its syntax for thoughts on the matter. One of the
funny things about E is that a promised variable would be replaced
with its fulfillment value when it becomes available (if I recall
correctly).

Kris Kowal

Wood, Joe

unread,
May 8, 2012, 8:50:11 AM5/8/12
to q-con...@googlegroups.com
Isn't this very similar to Iced Coffee Script's 'await' syntax?

http://maxtaco.github.com/coffee-script/

# Search for 'keyword' on twitter, then callback 'cb'
# with the results found.
search = (keyword, cb) ->
host = "http://search.twitter.com/"
url = "#{host}/search.json?q=#{keyword}&callback=?"
await $.getJSON url, defer json
cb json.results
===============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer:
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
===============================================================================

Kris Kowal

unread,
May 8, 2012, 1:01:13 PM5/8/12
to q-con...@googlegroups.com
On Tue, May 8, 2012 at 5:50 AM, Wood, Joe <joe....@credit-suisse.com> wrote:
> Isn't this very similar to Iced Coffee Script's 'await' syntax?

Not particularly, since it nests, but we *already* support await in
SpiderMonkey in this form:

var search = Q.async(function (keyword) {
var host = "http://search.twitter.com";
var url = host + "/search?q=" + encodeURIComponent(keyword);
var json = yield $.getJSON(url);
Q.return(json.results);
});

We hope the last line will reduce to a simple return and function will
become function* in the next standard for generators.

It isn’t hard to imagine a slightly abbreviated syntax catering to this usage.

Kris Kowal

Wood, Joe

unread,
May 8, 2012, 1:42:22 PM5/8/12
to q-con...@googlegroups.com

I can see that a generator could be used to represent the state machine of asynchronous calling pattern.  Is this really as nice as the await syntax though?  The simplicity of using await and defer for flattening out code that has sequences of I/O operations makes the code much more readable:

 

w_list = [ "sun", "rain", "snow", "sleet" ]

f_list = [ "tacos", "burritos", "pizza", "shrooms" ]

await rankPopularity w_list, defer weather

if weather.length

  await rankPopularity f_list, defer food

if weather.length and food.length

  await search "#{weather[0]}+#{food[0]}", defer tweets

  msg = tweets[0]?.text

alert if msg? then msg else "<nothing found>"

 

A similar syntax is used in C# 4.

 

Joe

 

-----Original Message-----
From: q-con...@googlegroups.com [mailto:q-con...@googlegroups.com] On Behalf Of Kris Kowal
Sent: Tuesday, May 08, 2012 1:01 PM
To: q-con...@googlegroups.com
Subject: Re: [Q] How about a "Q" language extension to JavaScript?

 

On Tue, May 8, 2012 at 5:50 AM, Wood, Joe <joe....@credit-suisse.com> wrote:



==============================================================================

Kris Kowal

unread,
May 8, 2012, 1:48:25 PM5/8/12
to q-con...@googlegroups.com
On Tue, May 8, 2012 at 10:01 AM, Kris Kowal <kris....@cixar.com> wrote:
> It isn’t hard to imagine a slightly abbreviated syntax catering to this usage.

To be explicit:

var search = Q.async(function (keyword) {
var host = "http://search.twitter.com";
var url = host + "/search?q=" + encodeURIComponent(keyword);
var json = yield $.getJSON(url);
Q.return(json.results);
});

Could be sugarized to:

var search = deferred function (keyword) {
var host = "http://search.twitter.com";
var url = host + "/search?q=" + encodeURIComponent(keyword);
var json = await $.getJSON(url);
return json.results;
});

The improvement is not very significant, event though it is
equivalently expressive, if not more.

If you’re arguing for the await "statement" instead of the
"yield/await" expression, it is certainly less expressive. Consider:


var search = deferred function () {
return {
x: await getX(),
y: await getY()
}
}

Kris Kowal
Reply all
Reply to author
Forward
0 new messages