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 14:47:36 -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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35575"; 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 20:48:38 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 1phaqc-0008ym-4r for ged-emacs-devel@m.gmane-mx.org; Wed, 29 Mar 2023 20:48:38 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1phapr-0007B8-Jj; Wed, 29 Mar 2023 14:47:51 -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 1phapm-0007Aj-4N for emacs-devel@gnu.org; Wed, 29 Mar 2023 14:47: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 1phapk-0000dZ-AY for emacs-devel@gnu.org; Wed, 29 Mar 2023 14:47:45 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id DDAC5442C81; Wed, 29 Mar 2023 14:47:42 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 9D112441613; Wed, 29 Mar 2023 14:47:40 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1680115660; bh=DD1Sw4qzut4YDW4JRMxlfh0jQr/3xEjsSI1iyJ5KDhk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=aHETsb4qix4oB/stMsjf/hWlqb3vzD+3a/yOrbXiBv5nYh/DOKcQtdIy3Ml/p7pGq xAP65FO7LxTAMGWzpzQHZq3Qwe06PQ/4/GqaFKkylyG4t1WarQNNytXUqUXXwxjGcm oH2wLVCq5zGG8H8CndPLqOoPglloLsXMhVN2iSTgUeqtH2DQGhL2yBDY0pIlh399bO LC8acRyr+lG9p1ouNpUv7b+cexuIYNl/QLsdIWu1AoeTUR0xzexUEe5iH4dWaWd70p uSU0SxM+fVRhi9bSkDzi4O5AI3Ctu/P4xYNm3ctDiPBzVLvs1KqpKInh6c08Q9/4ab a4as2wJh+L3bw== Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 4C0991232E4; Wed, 29 Mar 2023 14:47:40 -0400 (EDT) In-Reply-To: <87a6001xm0.fsf@logand.com> (Tomas Hlavaty's message of "Sat, 25 Mar 2023 19:42:31 +0100") 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:304825 Archived-At: >> Part of the issue is the management of `current-buffer`: should the >> composition of futures with `futur-let*` save&restore >> `current-buffer` to mimic more closely the behavior one would get >> with plain old sequential execution? If so, should we do the same >> with `point`? What about other such state? > > I do not think there is a good implicit solution. > Either it would save too much state or too little, > or save it the wrong way. Currently it doesn't save anything, which is "ideal" in terms of efficiency, but sometimes leads to code that's more verbose than I'd like. Someone suggested to save as much as threads do, but that's not practical. >> But as you point out at the beginning, as a general rule, if you want to >> avoid rewritings in the style of `generator.el`, then the code will tend >> to feel less like a tree and more "linear/imperative/sequential", >> because you fundamentally have to compose your operations "manually" >> with a monadic "bind" operation that forces you to *name* the >> intermediate value. > > That's what I suspected. > Being forced to name the values leads to very bad code. That's not my experience. It's sometimes a bit more verbose than strictly necessary, but it's quite rare for it to make the code less readable. > I do not want to block Emacs. > futur-wait blocks Emacs. `futur-wait` should be avoided as much as possible. But occasionally the context (i.e. the caller) wants an actual answer so you don't get to choose. E.g. when implementing `url-retrieve` you have to wait, by definition of what `url-retrive` does. `futur-wait` is provided for those use-cases. Most such uses reflect a problem/limitation elsewhere. AFAIK `futur-let*` corresponds more or less to Javascript's `await`, but I don't think Javascript provides an equivalent to `futur-wait`. Maybe I should use another name than `futur-wait`, like `futur-block-everything-annoyingly-until-we-get-the-result` to avoid the confusion? > I also do not understand, why would you use a timer and poll. > The functionality is edge triggered push model where this does not > make sense. I just showed how to "translate" your code into one that uses `futur.el`. `futur.el` doesn't magically change the algorithm. > (defun writer-process (buffer-name command writer) > (let* ((b (test-buffer buffer-name)) > (w (line-writer (proc-writer b writer)))) > (make-process :name buffer-name > :command command > :buffer b > :sentinel (writer-sentinel w) > :filter (writer-filter w)))) I haven't yet thought about how we could/should make `futur.el` useful for process filters (contrary to the use of process sentinels where the integration is more natural). > Why do you recommend to poll with futur.el? I don't. Stefan