Re: Announcing 8sync: an asynchronous programming language for Guile

[Amirouche Boubekki]

Le 2015-12-05 15:58, Christopher Allan Webber a écrit :
> Amirouche Boubekki writes:
> > * %8sync
> >
> > This is the main macro, here is it's definition:
> >
> > ```
> > (define-syntax-rule (%8sync async-request)
> >    (propagate-%async-exceptions
> >     (abort-to-prompt (current-agenda-prompt) async-request)))
> > ```
> >
> > I'm wondering whether (current-agenda-prompt) is useful.
> > I think the code will abort to the prompt of the current dynamic
> > context. So except if there is multiple agenda in the same thread,
> > it's not useful.
>
> You're right that this is the context in which this becomes useful.  I
> might have composed agendas at some point.  I'm not sure.
>
> > It's comparable to the way I define blocking procedures in async.scm
> >
> > ```
> > (define-public (read/ sock)
> >    (abort-to-prompt 'loop async-request))))
> > ```
>
> Right, that means that 'loop is always for "the agenda", and there will
> always be one.
>
> > where `async-request` is in `async.scm`:
> >
> > ```
> > (lambda (cc) (loop-add-reader sock (lambda () (cc (read sock)))))
> > ```
> >
> > It's the way `async.scm` does blocking calls (and *only* blocking
> > calls).  `read/` and its `async-request` is missing catch around
> > `read` and something like `propagate-%async-exceptions`.
>
> 8sync doesn't block though.  Its use of select means you only need to
> get information once it's available.
>
> The code you have here will block other code that is available to run
> while it's waiting for code.

I wrote "blocking" code in the sens that it is a call that blocks
when the port is not ready. In this case `read` is called
when the port is ready via the lambda registered as callback
with `loop-add-reader` which is called via select only when the port is 
ready.

It's similar to 8sync code, except there is not later dispatch like
in setup-async-request. Instead it's directly registers in the handler
of call-with-prompt.

The argument of the prompt is:

> > (lambda (cc) (loop-add-reader sock
> >                (lambda ()
> >                  (cc (read sock)))))

Which is called by the handle of call-with-prompt as callback:

```
    (call-with-prompt 'loop
      loop-run-once
      (lambda (cc callback) (callback cc)))))
```

Here cc is the continuation of the prompt handler.

tldr: There is certain number of proc that call each other
      in some order for the better good :)


> > 8sync has two types of async-request:
> >
> > ** run-requests, which implements kind of a *coroutine* behavior.
> >
> > It pause the execution of the current procedure and schedule
> > the provided lambda to be run soonish; This doesn't exists in
> > async.scm. The only thing useful this can do, is break the callstack
> > to allow deeper recursion.
>
> That's not true.  See the problems of "callback hell" people get into 
> in
> node.js.  8sync mitigates this.

Yes, but this must be mitigated only for calls that would block without
select.

> As for the callback stack, it does get broken that's true... but that's
> why 8sync gives you copies of all the stacks that were recursively
> called as it walks back through its ~futures upon some exception.

This is nice.

> I realize I disagreed with a lot of what you said, but a lot of the
> things you challenged are intentional designs in 8sync, not accidents.
>
> I do appreciate the feedback though, it helped me clarify some of the
> design decisions in 8sync, which will be useful for docs-writing!

Thanks for taking the time to respond it helps better understand.