From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: Proposal for a new (ice-9 history) Date: Tue, 30 Oct 2018 02:20:15 -0400 Message-ID: <878t2gklad.fsf@netris.org> References: <87lg6gmg9s.fsf@netris.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1540880356 4138 195.159.176.226 (30 Oct 2018 06:19:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 30 Oct 2018 06:19:16 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) Cc: guile-devel To: Mikael Djurfeldt Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Oct 30 07:19:12 2018 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gHNMt-0000wt-Pl for guile-devel@m.gmane.org; Tue, 30 Oct 2018 07:19:11 +0100 Original-Received: from localhost ([::1]:51074 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gHNOz-0000WD-PO for guile-devel@m.gmane.org; Tue, 30 Oct 2018 02:21:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33204) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gHNOj-0000W8-0D for guile-devel@gnu.org; Tue, 30 Oct 2018 02:21:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gHNOe-0000Pz-SV for guile-devel@gnu.org; Tue, 30 Oct 2018 02:21:04 -0400 Original-Received: from world.peace.net ([64.112.178.59]:33994) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gHNOe-0000Po-Ou for guile-devel@gnu.org; Tue, 30 Oct 2018 02:21:00 -0400 Original-Received: from mhw by world.peace.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gHNOd-0002Yj-HA; Tue, 30 Oct 2018 02:20:59 -0400 In-Reply-To: (Mikael Djurfeldt's message of "Tue, 30 Oct 2018 02:08:19 +0100") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 64.112.178.59 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.org gmane.lisp.guile.devel:19703 Archived-At: Hi Mikael, Mikael Djurfeldt writes: > On Tue, Oct 30, 2018 at 1:26 AM Mark H Weaver wrote: > > Mikael Djurfeldt writes: > > > The interface of (value-history) would instead have a lazy-binder > > which provides a syntax transformer for every $... actually being > > used. The $... identifier would expand into a list-ref into the value > > history. > > A few more suggestions: > > If I write (define (foo x) (+ $$0 x)) at the repl, then I expect 'foo' > to continue to refer to the same entry in the value history, even after > the value history is later extended. > > Well, this could be interpreted in two ways. What I expect is that $$0 > always refers to the last entry of the value history, even if it has > been extended, such that $$0 will evaluate to new values as new values > are pushed onto value history. I can see why it's a natural interpretation, but in practice this seems far less useful to me. I very often write procedures that reference values from the value history. In almost every case I can think of, I want those references to continue to refer to the same value in the future. If $$N has your preferred semantics, then it would almost always be a mistake to refer to $$N from within a procedure body. What use cases do you have in mind that would benefit from your preferred semantics for $$N? I can think of one case: it would enable writing procedures that magically operate on the most recent REPL result, or possibly the last two REPL results, to avoid having to pass them in explicitly as arguments. To support this use case, we could export a procedure from (ice-9 history) to fetch the Nth most recent value. Are there other realistic use cases that you know about? If you think that this is a sufficiently common use case to justify a special set of abbreviations, perhaps we could have just one or two magic variables to fetch the most recent values at run time? What do other people think? > This is also the effect we get if $$0 expands to (list-ref value-history 0). > > I'm also a bit concerned about the efficiency implications of expanding > these variable references into 'list-ref' calls when the history grows > large. If I write a loop that evaluates $$0 a million times, I'd prefer > to avoid a million 'list-ref' calls. > > Maybe this is a Microsoft-style argument, but do we really expect > users to use value history in that way? I do, FWIW. It's not uncommon for me to compute a value at the REPL, write a procedure that uses the value I just computed, possibly build more procedures on top of that, and then evaluate expressions that call the procedures repeatedly, e.g. from within loops. That said, I don't want to overstate the concerns about efficiency. I acknowledge that it's not very important either way. > If so, I guess value-history could be stored in a dynamically enlarged > vector. It would certainly help for efficiency, but it raises another issue, namely that we would need to think about thread safety issues. If a procedure that refers to $$N is entered at the REPL and then evaluated in another thread, the $$N could evaluate to garbage shortly after the value-history vector is enlarged, unless all accesses to $$N are serialized using a mutex. There's also another issue that just came to mind: multiple concurrent REPLs. Each REPL should have its own history, I think. Modern Guile offers REPL servers, which listen for network connections and spawn a new REPL thread for every incoming connection. We also have cooperative REPL servers that enable multiple REPLs within a single thread using cooperative threading, to avoid thread safety issues. Those require a procedure to be called periodically, and are intended for single-threaded programs based on event loops. It would be good to think about how to fix (ice-9 history) to properly support multiple concurrent REPLs in the same process. What do you think? Mark