From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jim Porter Newsgroups: gmane.emacs.devel Subject: Re: continuation passing in Emacs vs. JUST-THIS-ONE Date: Mon, 13 Mar 2023 23:28:12 -0700 Message-ID: <3cbee3b0-8eeb-2b6e-bd54-d949c38594bf@gmail.com> References: <627090382.312345.1678539189382@office.mailbox.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8744"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: rms@gnu.org, Thomas Koch Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Mar 14 07:29:14 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pby9p-000252-Kf for ged-emacs-devel@m.gmane-mx.org; Tue, 14 Mar 2023 07:29:13 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pby90-0000Z4-4l; Tue, 14 Mar 2023 02:28:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pby8x-0000YX-Dw for emacs-devel@gnu.org; Tue, 14 Mar 2023 02:28:20 -0400 Original-Received: from mail-pl1-x62e.google.com ([2607:f8b0:4864:20::62e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pby8v-0000AL-Ob; Tue, 14 Mar 2023 02:28:19 -0400 Original-Received: by mail-pl1-x62e.google.com with SMTP id u5so15506860plq.7; Mon, 13 Mar 2023 23:28:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678775295; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=+jtMK134MNUh0ROza4C5npAjUdZRDlmLtW9myhM4Y1A=; b=lAK8rTj5TjGqnrelKhz96/YrFIYSU0jHNMdbebhEagdv3IvgKkBMStzvBQCSAyKt/m BpYCkmTPGbemXsVekTj1IPBY7onrzUA3bh4wtrquP+q+P68WKV/2bWiRb2CoQEOVaAuK lYlCrm47KmvBG6yGoHC5gMmcJmvQgwrN8W2FmpG1mlT4GIIWuzWpLKNbPTRL/jnNZ5YW DlCBOrEUI+GWYpC4VBqsNHEDZ+0cYo5+JtX/q68Jx2vs4dvf7R0VfjnkEuug1FJGzNqb Kjb2SwZu93MWp9DkMVlXQC9fTWXlXE/XYnlf4aLFP3Xm+83mKcFOimnU5Ur7cn8eFOib l3ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678775295; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=+jtMK134MNUh0ROza4C5npAjUdZRDlmLtW9myhM4Y1A=; b=pP+rp79WU0vXAh8Rcz5tpNHfWyZrfnxqFrY5BjtO6GwMP5BNCxOqtkmNpqno8mmyYd pOsGdWS2ZIi1wgdVYGuoyAu+EvA9L8xgTQ0xkme6W7tkowJOsWtzccdgkgC/ipytWq+r kRkI5CsnT0Ju9lqicR0n/zeLBvISYTjY8yg9xNHmENsD42YzaKwwNlagXVBLJ77UzY99 alP9BMls2wUsOzVXBsWs+/zXzQ180MNxKj3eI7I/cQkLq7w5QRyjc6EhfLKzGayXiXaZ rIqvbMup+JSFs+x+LNsFAiLcA9424fc5B3BdztXTlb4pwK391dlEzdGQMISHBVNvddzZ 8P6A== X-Gm-Message-State: AO0yUKXlROM8Yyy9dd5F9YHunMCGq0CBVElcjeRTx3GXHiZ/yoigbMNx PQ9YAGkBX0R26dDed79f+8LSnSsW5qE= X-Google-Smtp-Source: AK7set9CSMHl+VcMEoS1dwOzksOz0xYdyw2Qh9Wtsyme4lSK2oa1R7OwEMVq1+Lh/zhDzpgENR0DgQ== X-Received: by 2002:a05:6a20:7da3:b0:be:e0c3:5012 with SMTP id v35-20020a056a207da300b000bee0c35012mr13461664pzj.1.1678775295479; Mon, 13 Mar 2023 23:28:15 -0700 (PDT) Original-Received: from [192.168.1.2] (cpe-76-168-148-233.socal.res.rr.com. [76.168.148.233]) by smtp.googlemail.com with ESMTPSA id k17-20020aa790d1000000b005a8173829d5sm747332pfk.66.2023.03.13.23.28.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Mar 2023 23:28:15 -0700 (PDT) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::62e; envelope-from=jporterbugs@gmail.com; helo=mail-pl1-x62e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:304423 Archived-At: 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'.