Re: continuation passing in Emacs vs. JUST-THIS-ONE

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> Part of the issue is the management of `current-buffer`: should the
>> composition of futures with `futur-let*` save&restore
>> `current-buffer` to mimic more closely the behavior one would get
>> with plain old sequential execution?  If so, should we do the same
>> with `point`?  What about other such state?
>
> I do not think there is a good implicit solution.
> Either it would save too much state or too little,
> or save it the wrong way.

Currently it doesn't save anything, which is "ideal" in terms of
efficiency, but sometimes leads to code that's more verbose than
I'd like.

Someone suggested to save as much as threads do, but that's not
practical.

>> But as you point out at the beginning, as a general rule, if you want to
>> avoid rewritings in the style of `generator.el`, then the code will tend
>> to feel less like a tree and more "linear/imperative/sequential",
>> because you fundamentally have to compose your operations "manually"
>> with a monadic "bind" operation that forces you to *name* the
>> intermediate value.
>
> That's what I suspected.
> Being forced to name the values leads to very bad code.

That's not my experience.  It's sometimes a bit more verbose than
strictly necessary, but it's quite rare for it to make the code
less readable.

> I do not want to block Emacs.
> futur-wait blocks Emacs.

`futur-wait` should be avoided as much as possible.  But occasionally
the context (i.e. the caller) wants an actual answer so you don't get
to choose.  E.g. when implementing `url-retrieve` you have to wait, by
definition of what `url-retrive` does.

`futur-wait` is provided for those use-cases.  Most such uses reflect
a problem/limitation elsewhere.

AFAIK `futur-let*` corresponds more or less to Javascript's `await`, but
I don't think Javascript provides an equivalent to `futur-wait`.

Maybe I should use another name than `futur-wait`, like
`futur-block-everything-annoyingly-until-we-get-the-result` to avoid
the confusion?

> I also do not understand, why would you use a timer and poll.
> The functionality is edge triggered push model where this does not
> make sense.

I just showed how to "translate" your code into one that uses
`futur.el`.  `futur.el` doesn't magically change the algorithm.

> (defun writer-process (buffer-name command writer)
>   (let* ((b (test-buffer buffer-name))
>          (w (line-writer (proc-writer b writer))))
>     (make-process :name buffer-name
>                   :command command
>                   :buffer b
>                   :sentinel (writer-sentinel w)
>                   :filter (writer-filter w))))

I haven't yet thought about how we could/should make `futur.el` useful
for process filters (contrary to the use of process sentinels where the
integration is more natural).

> Why do you recommend to poll with futur.el?

I don't.


        Stefan