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: Tue, 11 Apr 2023 16:22:18 -0400 Message-ID: References: <87leizif4r.fsf@logand.com> <874jpmfaw9.fsf@logand.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32080"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Jim Porter , Karthik Chikmagalur , "emacs-devel@gnu.org" To: Tomas Hlavaty Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Apr 11 22:23:21 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 1pmKWP-00086F-3W for ged-emacs-devel@m.gmane-mx.org; Tue, 11 Apr 2023 22:23:21 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pmKVX-0002mQ-Em; Tue, 11 Apr 2023 16:22:27 -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 1pmKVW-0002mF-2l for emacs-devel@gnu.org; Tue, 11 Apr 2023 16:22:26 -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 1pmKVT-0002dq-B6 for emacs-devel@gnu.org; Tue, 11 Apr 2023 16:22:25 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 0008F80DCA; Tue, 11 Apr 2023 16:22:19 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 809AF80223; Tue, 11 Apr 2023 16:22:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1681244538; bh=U9Cq/NpIzCMejEape+XAJu+2OTOsM0Izq3EfityoGjg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Sh17F+a/6ToXbMtQHpduS+G+jO6aY33YUQoT1/mXj3S7kiyUwjY/ZN4pdQRMjPA6i hHjIDdHBsYnzRIl+6pvdadHbl+8zeN7dC5q5tekZUZ/GMIYf3N+QeoYI5Tm7/OqRwr 0dwQBeVaCTShiVKRfIL3ttm43jc+nvnkW+OxmKjyVnQ2CBGHjwsr+Hxms/h9jRWIWJ scFNxw+X7T0SugbzKMkT5qvQXc7NVe07cW6JVNfJbapHhZ84hmjopaUfoaXd53y1/g lZ9t/fJeNboJlnDJvpnfUI3D1mYdNpjwpmZ6gm8ET5OZ29TFx0S/0d/ET6AAcFK6Ux bdy38gPknP69g== Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 6B941120255; Tue, 11 Apr 2023 16:22:18 -0400 (EDT) In-Reply-To: <874jpmfaw9.fsf@logand.com> (Tomas Hlavaty's message of "Tue, 11 Apr 2023 21:59:18 +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:305252 Archived-At: >> The idea is to use `futur.el` *instead of* threads. > What do you mean? > I can see thread-join and thread-signal in futur.el. It's only used to work around the current lack of an async version of process-send-string. > It is useful to acknowledge, that there are 3 different use-cases: > a) asynchronous processes > b) threads > c) iter I can't see how `iter` would be a use case for futures. > My impression was that futur.el was trying to address a) and b) but now > you say it does address a) only. That is rather limited. Looking at existing code, iter and threads are virtually never used, so from where I stand it seems to cover the 99% cases. >>> No, the iter case does map directly to futures: >>> >>> (await >>> (async-iter >>> (let ((a (async-iter >>> (message "a1") >>> (await-iter (sleep-iter3 3)) >>> (message "a2") >>> 1)) >>> (b (async-iter >>> (message "b1") >>> (let ((c (async-iter >>> (message "c1") >>> (await-iter (sleep-iter3 3)) >>> (message "c2") >>> 2))) >>> (message "b2") >>> (+ 3 (await-iter c)))))) >>> (+ (await-iter a) (await-iter b))))) >> >> I must say I don't understand this example: in which sense is it using >> "iter"? I don't see any `iter-yield`. > > await-iter and async-iter macros are using iter under the hood. The point of `iter` is to provide something that will iterate through a sequence of things. Here I don't see any form of iteration. You seem to use your `iter`s just as (expensive) thunks (futures). Maybe what you mean by "iter" is the use of CPS-translation (implemented by `generator.el`)? >> `futur.el` also "queues the continuations in the event loop". > > I get: > > futur.el:97:8: Warning: the function =E2=80=98funcall-later=E2=80=99 is n= ot known to be > defined. Yup, it's defined in C currently. You can use (unless (fboundp 'funcall-later) (defun funcall-later (function &rest args) ;; FIXME: Not sure if `run-with-timer' preserves ordering between ;; different calls with the same target time. (apply #'run-with-timer 0 nil function args))) >> Of course. You could do something like >> >> (futur-let* >> ((a (futur-let* ((_ <- (futur-process-make >> :command '("sleep" "9")))) >> 9)) >> (b (futur-let* ((_ <- (futur-process-make >> :command '("sleep" "8")))) >> 8)) >> (a-val <- a) >> (b-val <- b)) >> (message "Result =3D %s" (+ a-val b-val)))) > > So will futur.el take 9sec or 17sec? 9 secs, of course: the above creates 2 futures and emits the message when they're both done. Since those futures are executed in subprocesses, they execute concurrently. >> Similarly the "intended return value" of a process will depend on what >> the process does. In some cases it will be the stdout, but I see no >> reason to restrict my fundamental function to such a choice. > This overgeneralized thinking is beyond usefulness and harmfully leads > to the problem of how to maintain state. While I do like to over-generalize, in this case, there is no generalization involved. The code is the simple result of a thin wrapper around the existing `make-process` to make it obey the `futur.el` API. So if it's overgeneralized, it's not my fault, it's `make-process`s :-) Stefan