Re: 8sync tutorial part 1

[Christopher Allan Webber]

Marko Rauhamaa writes:

> Christopher Allan Webber <address@hidden>:
>
>>   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