From: Jim Porter <jporterbugs@gmail.com>
To: rms@gnu.org, Thomas Koch <thomas@koch.ro>
Cc: emacs-devel@gnu.org
Subject: Re: continuation passing in Emacs vs. JUST-THIS-ONE
Date: Mon, 13 Mar 2023 23:28:12 -0700 [thread overview]
Message-ID: <3cbee3b0-8eeb-2b6e-bd54-d949c38594bf@gmail.com> (raw)
In-Reply-To: <E1pbvoM-0005Ig-AR@fencepost.gnu.org>
On 3/13/2023 8:58 PM, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider ]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> > TL;DR: (Why) is there no standard way for continuation passing
> > style[1] ("event driven") programming in Emacs?
>
> I implemented Emacs Lisp using simple, natural C data structures
> including the C call stack. This does not lend itself to implementing
> continuations.
>
> To change that would be enormous trouble, and i expect it would cause
> a big slowdown too. In my opinion, continuation-passing style is not
> worth that downside.
There's already some support in Emacs for coroutines: generator.el
provides, well... generators, which should allow for most (all?) of what
you can normally do with coroutines, albeit with syntax that might not
be as fluent as we might like. This is implemented entirely in Lisp, so
I wouldn't be surprised if the performance suffers, but for certain
kinds of tasks where Emacs isn't CPU-bound, even that could be a
significant improvement for overall responsiveness.
For this thread in particular, I believe it's inspired by some issues
with Tramp, where (if I understand correctly), process filters from
relatively-long network operations are causing hangs (and also the
dreaded "forbidden reentrant call to Tramp" error). In these cases, I
think it's at least reasonably likely that the operations in question
are network/IO-bound, so slicing them up into continuations might be
good enough, even if those continuations have a performance penalty in
terms of CPU use.
Of course, without at least a simple proof of concept, it's hard to say
what the pros and cons look like. I'm hoping to test something like this
out in Eshell by using/adapting generator.el, since Eshell already
effectively contains its own CPS transformer called 'eshell-do-eval'.
next prev parent reply other threads:[~2023-03-14 6:28 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-11 12:53 continuation passing in Emacs vs. JUST-THIS-ONE Thomas Koch
2023-03-12 1:45 ` Jim Porter
2023-03-12 6:33 ` tomas
2023-03-14 6:39 ` Karthik Chikmagalur
2023-03-14 18:58 ` Jim Porter
2023-03-15 17:48 ` Stefan Monnier
2023-03-17 0:17 ` Tomas Hlavaty
2023-03-17 3:08 ` Stefan Monnier
2023-03-17 5:37 ` Jim Porter
2023-03-25 18:42 ` Tomas Hlavaty
2023-03-26 19:35 ` Tomas Hlavaty
2023-03-28 7:23 ` Tomas Hlavaty
2023-03-29 19:00 ` Stefan Monnier
2023-04-03 0:39 ` Tomas Hlavaty
2023-04-03 1:44 ` Emanuel Berg
2023-04-03 2:09 ` Stefan Monnier
2023-04-03 4:03 ` Po Lu
2023-04-03 4:51 ` Jim Porter
2023-04-10 21:47 ` Tomas Hlavaty
2023-04-11 2:53 ` Stefan Monnier
2023-04-11 19:59 ` Tomas Hlavaty
2023-04-11 20:22 ` Stefan Monnier
2023-04-11 23:07 ` Tomas Hlavaty
2023-04-12 6:13 ` Eli Zaretskii
2023-04-17 20:51 ` Tomas Hlavaty
2023-04-18 2:25 ` Eli Zaretskii
2023-04-18 5:01 ` Tomas Hlavaty
2023-04-18 10:35 ` Konstantin Kharlamov
2023-04-18 15:31 ` [External] : " Drew Adams
2023-03-29 18:47 ` Stefan Monnier
2023-04-17 3:46 ` Lynn Winebarger
2023-04-17 19:50 ` Stefan Monnier
2023-04-18 2:56 ` Lynn Winebarger
2023-04-18 3:48 ` Stefan Monnier
2023-04-22 2:48 ` Lynn Winebarger
2023-04-18 6:19 ` Jim Porter
2023-04-18 9:52 ` Po Lu
2023-04-18 12:38 ` Lynn Winebarger
2023-04-18 13:14 ` Stefan Monnier
2023-04-19 0:28 ` Basil L. Contovounesios
2023-04-19 2:59 ` Stefan Monnier
2023-04-19 13:25 ` [External] : " Drew Adams
2023-04-19 13:34 ` Robert Pluim
2023-04-19 14:19 ` Stefan Monnier
2023-04-21 1:33 ` Richard Stallman
2023-04-19 1:11 ` Po Lu
2023-04-17 21:00 ` Tomas Hlavaty
2023-03-14 3:58 ` Richard Stallman
2023-03-14 6:28 ` Jim Porter [this message]
2023-03-16 21:35 ` miha
2023-03-16 22:14 ` Jim Porter
2023-03-25 21:05 ` Tomas Hlavaty
2023-03-26 23:50 ` Tomas Hlavaty
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3cbee3b0-8eeb-2b6e-bd54-d949c38594bf@gmail.com \
--to=jporterbugs@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=rms@gnu.org \
--cc=thomas@koch.ro \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
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).