-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
introduce tamejs-style asynchronous constructs to avoid callback pyramids #1710
Comments
I'd like to suggest that coffescript stay backwards compatible with vanilla JavaScript by using one (or some) of the flow-control micro-libraries that also work in the browser. For example
Could become
The big issues are
I could make a library more focused and lightweight than FuturesJS just for this purpose with a syntax such as
I'm not yet a heavy CoffeeScript user, but CoffeeScript is a leader in the community and so my interest in the direction of this is that whatever conventions CoffeeScript adopts, for better or for worse, will likely be backported to vanilla JavaScript and gain long-term traction. |
(Note: I guess I'm technically a TameJS contributor but I've only submitted one bug report. I've also played around with StreamlineJS a bit, and with a couple of flow control libraries. I haven't found a silver bullet yet.) I think the key here is to clearly enumerate the problem that needs to be solved and then work from there to a syntax to solve it. Otherwise, you're doomed by people arguing that another is a system that's better for solving their particular view of the problem. As I see it, problems that flow control libraries/flow control precompilation steps solve include:
Empirically, different library/language designers have attributed very different weights to the 4 problems. To the best of my understanding, as a result, historically, the Coffeescript community has claimed that problem (1) is solved by Coffeescript's better functions syntax, that (4) is solved by flow control libraries, and that (2) and (3) aren't significant enough to add a continuation transformation step. |
I've been trying to argue the merits of the Tame way of programming for about 5 years now, and I've long since given up on trying to convince anyone to use it who otherwise is dead set against it. However, I just wanted to add three small points to this discussion.
void function foo (callback)
{
if (/*something*/) {
callback();
return;
} else if (/* something else */) {
// BUG! You forgot to callback() and your program will hang.
return;
}
// other stuff
callback ();
}
|
/subscribing to this |
@michaelficarra To clarify, are you proposing we compile coffeescript into tamejs, which would then be compiled by tamejs into vanilla javascript, or are you proposing we make our own tamejs-flavored language features that compile directly into js? |
@benekastah: I'm proposing we compile to JS-with- |
Flow control is becoming the norm on both the client side and server. It sure would be nice if coffeescript provided a simple way to implement async coding. Looked over tamejs. Looks awesome. Been wrestling with a few others but was not happy with the results. Sadly it appears to only run server side. |
Hasn't this all been done before in #350 ? |
Work in progress here: https://github.com/maxtaco/coffee-script I'll hope to have a pull request sometime soon to pick apart. Just met with @jashkenas who had some great suggestions. |
Awesome. Looking forward to it. How did @jashkenas feel about the ugliness of the CPS compilation? I believe that was the main argument holding this feature back. |
Turns out @maxtaco works right around the corner ... we talked about the ugliness of the CPS transformation, but that wasn't the only thing holding back previous versions of
... @maxtaco has already solved most of these. The defer/await split allows you to get either sequential or parallel behavior; he has a pretty clean addition to the AST (although it can still use a bit more cleaning up); special values for deferring in loops are only emitted when you actually defer in a loop; and so on. I think that there's more ground to be covered to boil down the generated code to the minimum amount that we can lexically determine is necessary for the particular "defer" use -- but hopefully y'all (and maybe @gfxmonk as well) can help with that. |
/subscribing to this thread |
/s |
Update: I moved over from master to the "tame" branch in my repo in preparation for the pull request. I added a fair amount of documentation to TAME.md. Before I submit, though, I thought we'd get some more experience using it in practice. We've already found a few a bugs, and maybe a few more will show up. More to come. |
Is that a call to action? You want us to start testing this? |
No, sorry for the confusion, we're testing it in-house! On Tue, Dec 13, 2011 at 3:00 PM, Jason King <
|
Another tweet-sized update, we're dogfooding and finding about a bug a day. The reg test suite is growing nicely. The recent bugs have had to do with scoping or |
Any update on this? |
any news? |
Closing in favor of #3757. |
twait
is now calledawait
andmkevent
is now calleddefer
. Luckily, they don't appear to have changed any of the semantics, though I haven't looked that hard. Take that into account when checking out tamejs.A few months ago, I was checking out tamejs, liked the ideas, and started thinking about how it could be incorporated into coffeescript. For the uninitiated: tamejs basically just takes the JS you write and compiles it to use continuation-passing style. So the output's not so pretty. Anyway, I took a few of the examples from the website, pasted them into a gist, and rewrote them in what I called "imaginary-coffeescript-with-defer". I'll include one gist inline and just link to the other.
Imaginary CoffeeScript
Original tamejs Example
There's a pretty simple mapping from the added coffeescript constructs to the tamejs additions.
defer
block is just one bigtwait
(arg0, arg1, ..., argN) <- expression
:twait
unless inside adefer
*
(or whatever syntax we pick) insideexpression
*
(or whatever syntax we pick) compiles tomkevent
using args from containing<-
Now I'm not sure how appropriate it would be to add to CS because of the possibly irreparably ugly compilation. But I think it's worth a discussion even considering the numerous, extremely lengthy tickets on
defer
-style constructs. Hell, I think people would sacrifice the readable output for a powerful feature like that. And they would only need to do so when using that feature.I think it makes a really good use of both
<-
anddefer
. That syntax just really seems to fit their proposed functionality.Pinging list of tamejs contributors: @maxtaco, @malgorithms, @m8apps, @frew
The text was updated successfully, but these errors were encountered: