From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tomas Hlavaty Newsgroups: gmane.emacs.devel Subject: Re: continuation passing in Emacs vs. JUST-THIS-ONE Date: Tue, 28 Mar 2023 09:23:21 +0200 Message-ID: <87v8ilz6dy.fsf@logand.com> References: <627090382.312345.1678539189382@office.mailbox.org> <87sfe7suog.fsf@gmail.com> <1c6fedae-10b4-5d97-5036-eaa736e1b816@gmail.com> <87mt4c6xju.fsf@logand.com> <87a6001xm0.fsf@logand.com> <87tty78fwg.fsf@logand.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11906"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Jim Porter , Karthik Chikmagalur , Thomas Koch , "emacs-devel@gnu.org" To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Mar 28 09:24:04 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 1ph3gZ-0002kp-B8 for ged-emacs-devel@m.gmane-mx.org; Tue, 28 Mar 2023 09:24:03 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ph3gE-0005kF-94; Tue, 28 Mar 2023 03:23:42 -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 1ph3g7-0005iB-PT for emacs-devel@gnu.org; Tue, 28 Mar 2023 03:23:37 -0400 Original-Received: from logand.com ([37.48.87.44]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ph3g6-0006Ho-9G for emacs-devel@gnu.org; Tue, 28 Mar 2023 03:23:35 -0400 Original-Received: by logand.com (Postfix, from userid 1001) id 7197A19E638; Tue, 28 Mar 2023 09:23:23 +0200 (CEST) X-Mailer: emacs 28.2 (via feedmail 11-beta-1 I) In-Reply-To: <87tty78fwg.fsf@logand.com> Received-SPF: pass client-ip=37.48.87.44; envelope-from=tom@logand.com; helo=logand.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-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:304795 Archived-At: On Sun 26 Mar 2023 at 21:35, Tomas Hlavaty wrote: > On Sat 25 Mar 2023 at 19:42, Tomas Hlavaty wrote: >>> I don't think so, no. But you would need fancy rewriting if you wanted >>> to allow >>> >>> (concat foo (futur-let* (...) ...)) > > or one could do it explicitly: > > (concat foo (future-wait (futur-let* (...) ...))) Looking at other languages, they do it explicitly. The reason is, that one might want to save the future, do something else and await the future later at some point. Not await it immediately: (let ((future (futur-let* (...) ...))) ... (concat foo (future-wait future)))