From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: continuation passing in Emacs vs. JUST-THIS-ONE Date: Wed, 29 Mar 2023 15:00:38 -0400 Message-ID: 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="28338"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Jim Porter , Karthik Chikmagalur , Thomas Koch , "emacs-devel@gnu.org" To: Tomas Hlavaty Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Mar 29 21:01:28 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 1phb2z-00074V-GR for ged-emacs-devel@m.gmane-mx.org; Wed, 29 Mar 2023 21:01:25 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1phb2O-0001XE-9W; Wed, 29 Mar 2023 15:00:48 -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 1phb2M-0001Wu-EZ for emacs-devel@gnu.org; Wed, 29 Mar 2023 15:00:46 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1phb2K-0003lC-Ol for emacs-devel@gnu.org; Wed, 29 Mar 2023 15:00:46 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 9324E80A14; Wed, 29 Mar 2023 15:00:42 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 12B0680800; Wed, 29 Mar 2023 15:00:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1680116441; bh=Iz+XOOrOv+ktwQyu6qdc7u2h7/9h1KGvVfhMhim5bHc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ZWKWkXd14b+hK5OBaYL3CL1ScTqG+rwq6LBl5mda4c2OmuG/85iS3Ug48wr0+fG8m emFndFDDey4iaxyGAlHzwL1xzTmkiY9Lp5ZtMbZ3FkSNkJQpm2ur4f5dMFXbIA391k zsHextN0OSZnUxtYdFwj0psOyGP+z/lMX2GR/poZPaKGkj6oTfBMdvIPDKg1iXUhFA bw86WAAsvLtokC7fQl2erdLFHL7cx+YpRx5y+db1i8lqHfD0rrL2jyY4mtgaw6BdiG FF5/wccPQCpR046GZngtu9e0kEBJmJg9K39KVW5Z4t/N+SuJupkqEEAqELbHr38kY7 40Lx9llmvwa/A== Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C604E1232C9; Wed, 29 Mar 2023 15:00:40 -0400 (EDT) In-Reply-To: <87tty78fwg.fsf@logand.com> (Tomas Hlavaty's message of "Sun, 26 Mar 2023 21:35:27 +0200") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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:304826 Archived-At: > (defun await (future) > (let (z) > (while (eq 'EAGAIN (setq z (funcall future))) > ;; TODO poke sit-for/io on yield? how? > (sit-for 0.2)) > z)) This blocks, so it's the equivalent of `futur-wait`. I.e. it's the thing we'd ideally never use. > Assuming alet (async let) macro, which binds var when async process > finishes with the value of its output: I.e. what I called `future-let*`. > (alet p1 '("which" "emacs") > (when p1 > (alet p2 `("readlink" "-f" ,p1) > (when p2 > (message "@@@ %s" p2))))) Your syntax is more concise because it presumes all your async objects run commands via `make-process`, but other than that it seems to be doing basically the same as my code, yes. > or even await async process inside async process: > > (await > (async > (alet p `("readlink" "-f" ,(await > (async > (alet p '("which" "emacs") > (when p > (yield p)))))) > (when p > (yield p))))) You use `await` which will block Emacs :-( > I think this provides nicer interface for async code than futur.el and > even comes with a working example. I think you just reinvented the same thing, yes :-) >> (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))) I suspect that a better option would be instead of: (let ((future (futur-let* (BINDS...) BODY))) ... (concat foo (future-wait future))) to use (futur-let* (BINDS... (s BODY)) (concat foo s)) The difference is that it doesn't return a string but a `futur`, so if you want the string you need to use `future-let*` or `futur-wait`. The advantage is that you still have the choice to use `future-let*` rather than `futur-wait`. Stefan