unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
* 8sync tutorial part 1
@ 2016-04-24 20:22 Christopher Allan Webber
  2016-04-24 21:06 ` Marko Rauhamaa
  0 siblings, 1 reply; 4+ messages in thread
From: Christopher Allan Webber @ 2016-04-24 20:22 UTC (permalink / raw)
  To: guile-user

Hello all,

I'm working on some tutorials for 8sync, and working on incorporating
them into the manual.  But for now all I have is an orgmode export.
Behold:

  http://dustycloud.org/tmp/8sync-tutorial-part1.html

It gets into the basics of the agenda, using delays to keep things
simple.  It's fairly imperative, and could be less so, I know we have a
lot of functional purists on the list, but I felt the example could be
shorter and simpler with a bit of mutation.  (It uses GOOPS too; 8sync
itself does not require GOOPS... but I'll admit I kinda like GOOPS!)

IO / ports stuff is coming in the next chapter.  I'm thinking maybe
the next chapter will be "write an irc bot from scratch" but I don't
know yet.

 - Chris



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: 8sync tutorial part 1
  2016-04-24 20:22 8sync tutorial part 1 Christopher Allan Webber
@ 2016-04-24 21:06 ` Marko Rauhamaa
  2016-04-24 22:15   ` Christopher Allan Webber
  0 siblings, 1 reply; 4+ messages in thread
From: Marko Rauhamaa @ 2016-04-24 21:06 UTC (permalink / raw)
  To: Christopher Allan Webber; +Cc: guile-user

Christopher Allan Webber <cwebber@dustycloud.org>:

>   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".

 * 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)

   or -- in this particular case --

     (run-delay hello-snore 1)

 * I'm guessing the "run-delay" macro as well as "start-agenda" operate
   on a singleton, global context. I'd advice making that context
   visible and explicit:

     (define 8sync (make-8sync))

     (define (hello-snore)
        ...
        (run-delay 8sync hello-snore 1))

     (start-agenda 8sync (make-agenda ...))

> IO / ports stuff is coming in the next chapter.

That's when things will get interesting. Looking forward to the
installment.

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!


Marko



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: 8sync tutorial part 1
  2016-04-24 21:06 ` Marko Rauhamaa
@ 2016-04-24 22:15   ` Christopher Allan Webber
  2016-04-25  4:50     ` Marko Rauhamaa
  0 siblings, 1 reply; 4+ messages in thread
From: Christopher Allan Webber @ 2016-04-24 22:15 UTC (permalink / raw)
  To: Marko Rauhamaa; +Cc: guile-user

Marko Rauhamaa writes:

> Christopher Allan Webber <cwebber@dustycloud.org>:
>
>>   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



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: 8sync tutorial part 1
  2016-04-24 22:15   ` Christopher Allan Webber
@ 2016-04-25  4:50     ` Marko Rauhamaa
  0 siblings, 0 replies; 4+ messages in thread
From: Marko Rauhamaa @ 2016-04-25  4:50 UTC (permalink / raw)
  To: Christopher Allan Webber; +Cc: guile-user

Christopher Allan Webber <cwebber@dustycloud.org>:

> Marko Rauhamaa writes:
>>      (run-delay (lambda (hello-snore)) 1)
>
> I'm not sure how this one would run...

Typo on my part: (lambda () (hello-snore))


Marko



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2016-04-25  4:50 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-04-24 20:22 8sync tutorial part 1 Christopher Allan Webber
2016-04-24 21:06 ` Marko Rauhamaa
2016-04-24 22:15   ` Christopher Allan Webber
2016-04-25  4:50     ` Marko Rauhamaa

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).