Marko Rauhamaa writes: > Christopher Allan Webber <[email protected]>: > >> http://dustycloud.org/tmp/8sync-tutorial-part1.html >> >> It gets into the basics of the agenda, using delays to keep things >> simple. > > Comments: > > * A typo: The text talks about "run-at" but the example has > "run-delay".
You're right! Fixed. Run-at exists, but is not what we're using here. > * I'm guessing "run-delay" is a macro. In my opinion you should use > macros very sparingly. Here, the only point of the macro seems to be > to avoid a "lambda". I would prefer: > > (run-delay (lambda (hello-snore)) 1) I'm not sure how this one would run... > or -- in this particular case -- > > (run-delay hello-snore 1) Anyway, yes you're right, run, run-at, and foo are all macros to simplify things. As said in the document though, you don't have to use them. They're very lightweight sugar around (make-run-request). The tutorial even shows you how to not use them and construct the run-request yourself! The run-request gets sent back to the agenda, and is used to build the next step of the queue. You can always return your own run-request object. The (8sync (run-this-func 'some-arg)) stuff however *does* use a macro in a way that's not easy to do yourself. You could do it on your own, but the macro takes care of a lot of stuff very carefully for you: constructing the promise, aborting to the prompt, taking the information returned from the asynchronously run procedure and returning it, and catching errors in the asynchronous procedure and re-raising them in the original procedure (!!!!) which are all nice features. I tried looking into how to do these with just procedures, but I found no nice way to do it. You don't have to use the (8sync) special form, though, and just break things up into a lot of manual procedures which return run-requests. It *will* make your life a lot easier to use the (8sync) special form though. > * I'm guessing the "run-delay" macro as well as "start-agenda" operate > on a singleton, global context. They don't, so that assumption is wrong. The only "global" in the system is that there's a parameterized prompt that is aborted to if you use the (8sync) special form. Again, if you just return run-request objects at the end of the procedure call and don't use (8sync) that's never even brought into play. But aborting via delimited continuations is too good of a win. Even there, you could avoid the parameter! You could pass in the prompt symbol to every function you might want to abort to. It would require a lot of manual plumbing, or a lot of complicated monad massaging, but you can do it today as-is with the existing library. But you'd have to do all the work that the (8sync) special form does for you, and my guess is that by the time you start working your way through that, you'll find that it makes your life a lot easier. >> IO / ports stuff is coming in the next chapter. > > That's when things will get interesting. Looking forward to the > installment. Yes, I think so too. :) > Warning: I actually *like* the callback hell, which you have said you > want to avoid. On the other hand, the first chapter of the tutorial > seems to consist of nothing but callbacks! Nothing but callbacks with the exception of the (8sync-delay), and that's true :) If you like callback hell, you can live in it with 8sync too... that's totally compatible with 8sync's agenda! 8sync just provides a path out, if you want it. Thanks for the feedback! - Chris
