Welcome to the community of async library authors. I wrote one when I started node. There is no better way to learn the ins and outs of async programming.
I switched back to straight async code as did many other authors. It is like learning how to ride a bicycle. All the hell goes away and simple code flows out. On Tue, Dec 11, 2012 at 10:02 AM, Jonathan Dickinson <jonathand...@gmail.com> wrote: > Oh wow. That's awesome: I had no idea that these projects existed. The > approach with the defer keyword is incredibly interesting (I assume the > existence of some promise library, like JQuery or node-promise). For what > it's worth I set out to avoid heavy dependence on the stack: it seems that > after some brief testing Iced and Tame are quite resilient to this. > > They are compiled really differently to mine: just take a look at the > comparative output. > > Some criticisms: > > Iced can't compile this: await (await test(baz, defer), defer) > Not surprising, it could be seen as ambiguous, but this is currently > compiling (and running) locally for me: await test(await baz(), await > blaz()); > Tame doesn't deal with exceptions too well. Likely because their compilation > technique is very different to mine (maybe because they make 'typical' > continuations, or, because they don't use promises). I can't tell if Iced > does. > After some searching I couldn't tell if either of them have sourcemap > support. > > I'm not convinced I should continue with asyncscript though. Those are > pedantic criticisms at best (except for the sourcemap: Iced results in > pretty hard to debug code - which I am sure will be supported eventually). > > Thanks for the heads-up. > > On Tuesday, 11 December 2012 17:59:03 UTC+2, Forrest L Norvell wrote: >> >> From a brief look, this looks very similar to the model used by TameJS or >> Iced CoffeeScript, both of which use an approach rooted in await / deferred >> semantics and AST parsing and rewriting. Are you aware of those projects? If >> so, how is your approach different? Also, aside from slightly terser syntax, >> what does this approach offer over promises, which don't require a >> preprocessing step? >> >> I don't intend to sound dismissive or hostile, but there are a massive >> number of flow control libraries for JS / Node, and a considerable amount of >> this list's history tied up in arguing their relative merits, which is part >> of the reason why Node has such a minimal / primitive model for dealing with >> continuations in the first place. New flow control tools are unlikely to see >> much uptake unless they bring something significant and new (that justifies >> the time taken to learn them and the cost of maintaining code that looks >> different from more idiomatic JS) to the table. >> >> F >> >> On Monday, December 10, 2012, Jonathan Dickinson wrote: >>> >>> Hi All, >>> >>> I just started my first foray into javascript beyond the usual minimal >>> glue I was used with browsers. After looking at some node tutorials the >>> first thing I noticed was the CPS hell (honestly, no way in hell I am >>> dealing with that ;)). I present an extremely rough draft of asyncscript; it >>> modelled after (black-box) looking at how C# implements its async. >>> https://github.com/jcdickinson/asyncscript >>> >>> The metacompiler first takes an AST (lightly modified acorn.js) and turns >>> in into IR. The IR basically adds blocks and closures to the AST, so you >>> essentially land up with: >>> >>> Closure >>> >>> Block1 >>> >>> AST >>> >>> Block2 >>> >>> AST >>> >>> Block3 >>> >>> AST >>> Closure >>> >>> ... >>> >>> AST >>> >>> Blocks are breaks in real execution (read: continuations - although I >>> will also need to [ab]use them for branching constructs in the presence of >>> the async keyword). The IR is then passed off to a few transformation stages >>> (async, if, &&/||, while, for - of which only async is implemented). So for >>> example, the async transform will create a split in the block (resulting in >>> two blocks) at the statement containing the async keyword. >>> >>> Closure (async) >>> >>> Block1 >>> >>> AST that was in Block1 before await >>> await >>> >>> Block2 >>> >>> grab async result >>> AST that was in Block1 after await >>> >>> Finally the IR is turned into JS. Due to the lack of a goto statement in >>> JS I needed to implement 'transitioning' blocks (if, and other >>> non-continuation branches) as a while loop: >>> >>> var state = 0; >>> while(true) { >>> switch(state) { >>> case 0: >>> blar(); >>> state = 1; // Effectively a goto >>> break; >>> case 1: >>> baz(); >>> return; >>> } >>> } >>> >>> Yes, it's ugly, but I would rather have ugly code than bloating the call >>> stack (please, does anyone has any better ideas how to do this without >>> wasting stack space?). 'sequencing' blocks simply return out of the function >>> after registering the continuation. So at the end of the day you get: >>> >>> asyncscript: >>> var username = "jimbob"; >>> var settings = await httpGetAsync("http://myserver/?username="; + >>> username); >>> await displaySomeModal(settings); >>> >>> javascript (tidied): >>> (function () { >>> var state = 0; >>> var awaiter = createAwaiter(); >>> function continuation() { >>> try { >>> var result = arguments[1]; >>> if (typeof arguments[2] !== 'undefined') throw arguments[2]; >>> state = arguments[0]; >>> while (true) { >>> switch (state) { >>> case 0: { >>> username = "jimbob"; >>> await(continuation, 1, >>> httpGetAsync("http://myserver/?username="; + username)); >>> return; >>> } >>> case 1: { >>> tmp = result; >>> settings = tmp; >>> await(continuation, 2, >>> displaySomeModal(settings)); >>> return; >>> } >>> case 2: { >>> completeAwaiter(continuation); >>> return; >>> } >>> default: >>> throw 'The runtime has become unstable.'; >>> } >>> } >>> } catch (error) { >>> completeAwaiter(continuation, null, error); >>> return; >>> } >>> } >>> continuation(0); >>> return createPromise(awaiter); >>> })(); >>> >>> As I said, this is my first serious attempt at JS - so I might have made >>> some obvious mistakes (quite possibly messing up the closure semantics, but >>> I think I got it right). Feel free to tell me (in a justified way) how I am >>> a noob :), also remember that this is a draft: so a very small amount of the >>> JS syntax is actually implemented. I would just like some feedback before >>> making something that is complete but blatantly incorrect. >>> >>> I am also [ab]using AMD for the purposes of loading in different >>> 'runtimes' (code generators that define how e.g. completeAwaiter and >>> createPromise, are generated) for the purposes of e.g. jquery v.s. >>> node-promise. I might be doing the totally wrong thing, but thought it was >>> pretty cool. I will also fix the folder layout some time later: at the >>> moment it hacks in intellisense support for VS2012. >>> >>> If you think it's beyond help and want to re-implement it, I don't mind >>> at all: I would be happy to contribute code and ideas to a repo maintained >>> by someone who knows what they are doing. >>> >>> -- >>> jcd >>> >>> -- >>> Job Board: http://jobs.nodejs.org/ >>> Posting guidelines: >>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines >>> You received this message because you are subscribed to the Google >>> Groups "nodejs" group. >>> To post to this group, send email to nodejs@googlegroups.com >>> To unsubscribe from this group, send email to >>> nodejs+unsubscr...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/nodejs?hl=en?hl=en > > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to nodejs@googlegroups.com > To unsubscribe from this group, send email to > nodejs+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
