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

[Stefan Monnier]

> This whole thread seems to echo the difference between "stackless" and
> "stackful" coroutines discussed in
> https://nullprogram.com/blog/2019/03/10/ by the author of emacs-aio,
> with generator-style rewriting corresponding to stackless and threads
> to "stackful".  So when you say "save as much as threads do", I'm not
> clear if you're talking about rewriting code to essentially create a
> heap allocated version of the same information that a thread has in
> the form of its stack, or something more limited like some particular
> set of special bindings.

Indeed to "save as much as threads do" we'd have to essentially create
a heap allocated version of the same info.
[ I don't think that's what we want.  ]

> It seems to me what one would really like is for primitives that might
> block to just return a future that's treated like any other value,
> except that "futurep" would return true and primitive operations would
> implicitly wait on the futures in their arguments.

I think experience shows that doing that implicitly everywhere is not
a good idea, because it makes it all too easy to accidentally block
waiting for a future.

Instead, you want to replace this "implicit" by a mechanism that is "as
lightweight as possible" (so it's "almost implicit") and that makes it
easy for the programmer to control whether the code should rather block
for the future's result (e.g. `futur-wait`) or "delay itself" until
after the future's completion (e.g. `future-let*`).

> I think that would provide the asynchronous but not concurrent
> semantics you're talking about.

FWIW, I'm in favor of both more concurrency and more parallelism.
My earlier remark was simply pointing out that the design of `futur.el`
is not trying to make Emacs faster.


        Stefan