From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Mikael Djurfeldt Newsgroups: gmane.lisp.guile.devel Subject: Re: Proposal for a new (ice-9 history) Date: Tue, 30 Oct 2018 14:59:10 +0100 Message-ID: References: <87lg6gmg9s.fsf@netris.org> <878t2gklad.fsf@netris.org> Reply-To: mikael@djurfeldt.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000cfc04c0579729778" X-Trace: blaine.gmane.org 1540907905 27398 195.159.176.226 (30 Oct 2018 13:58:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 30 Oct 2018 13:58:25 +0000 (UTC) Cc: guile-devel To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Oct 30 14:58:21 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 1gHUXE-00071w-Sr for guile-devel@m.gmane.org; Tue, 30 Oct 2018 14:58:21 +0100 Original-Received: from localhost ([::1]:53434 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gHUZL-00043e-CP for guile-devel@m.gmane.org; Tue, 30 Oct 2018 10:00:31 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34182) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gHUYX-0003gj-KH for guile-devel@gnu.org; Tue, 30 Oct 2018 09:59:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gHUYR-0002Gl-Uw for guile-devel@gnu.org; Tue, 30 Oct 2018 09:59:41 -0400 Original-Received: from mail-oi1-f170.google.com ([209.85.167.170]:33334) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gHUYR-0002BJ-Fe for guile-devel@gnu.org; Tue, 30 Oct 2018 09:59:35 -0400 Original-Received: by mail-oi1-f170.google.com with SMTP id c25-v6so10484917oiy.0 for ; Tue, 30 Oct 2018 06:59:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=avXdXCWKwFVKwx/s6KlC644exEZfvU7eSsLGGRZXAvc=; b=Fjk9HkdzGQZU1pXNpleQ8/ImFuLQmrHVKVibuIrAzTSFyAtBZcH2Vv4cEZSqPTOPx0 G1N90hSGskTX5NQdGvYjv6CrTOru183gyVNs8tCPswt9hgKZ7F8DjiYSZeuL+ukgm/hB 0mReBx8Yf+9lSiMsoGDS7HbmNUOx5r11cJHPZQHcojzDRA+FNCFz2aKS3WUE7SX+a8MF /bZOEUQPjsb2USz9MLhxh/VY0ZDjxbA0rDEa5Sj+V8NI0IPo/vyz3Y5j6DJmkTMRHKbH uNDccxW5xL4+xpfONE1csNvRSQMcsO/W9e/cmIrHqUsOgznC/bYGSWy6ClFbrn9sqJ0l z1uA== X-Gm-Message-State: AGRZ1gJbbqB+6b8MvhVontCtZYaoC2vQlUh5TOOILH6RXP/0X3MFb49v 2j2dvIVE2okJ7QorU2e8ZKMEolEh84byUCXLpHyzFthq X-Google-Smtp-Source: AJdET5c00N7rJw4q0s1pgMjT/OplpRrPTWCWWq4eBZFU1qXln0mlOkB1hOkxdWq1eGaPcHEmtTBJY6SFEfyRi1X6rl4= X-Received: by 2002:aca:3788:: with SMTP id e130-v6mr11623836oia.117.1540907963759; Tue, 30 Oct 2018 06:59:23 -0700 (PDT) In-Reply-To: <878t2gklad.fsf@netris.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.167.170 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:19706 Archived-At: --000000000000cfc04c0579729778 Content-Type: text/plain; charset="UTF-8" On Tue, Oct 30, 2018 at 7:21 AM Mark H Weaver wrote: > 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? > I actually don't have other use-cases other than using value-history in expressions on the command line. My only concern is about the complexity of the semantics. I don't have very strong objections to the semantics you suggest, though. But note, again, that your semantics depends on macro expansion time, such that, e.g., if one would be crazy enough to put this in a file and load it in, then it would behave entirely differently. However, my feeling is that if one really wanted to do real programming against value-history, then the (ice-9 history) module should export suitable selectors with well-defined semantics. Your argument that you find it useful that the value referred to becomes fixed at macro expansion time is sufficient to me to accept it, but let's hear what other people think about it. Note that this issue is independent of whether we use bindings in a module or a list. The list-ref version would simply be a reference relative to "count", and your value would be fixed as per your requested semantics. > 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? > No, I think that if we implement backward references, then we should be able to pick any value. One or two would be frustrating in many situations. Another possible syntax would be that $-1 refers to the most recent value, and then we could have $-2, $-3, etc. It would all be consistent if value history started out with $0 = ... . Dunno. > > 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? > You raise an important issue. Since every REPL runs with its own dynamic state, perhaps a par of fluids would help? Ive noticed Ludovic's (ice-9 vlist) which, as a functional datastructure, would mesh well with a fluid. At the same time it at least partially addresses your concern regarding efficiency since at least the most recent history values would be accessed at O(1). So, history would be stored as a vlist in a fluid and $... references would expand to vlist-ref. What do you think? Is it a problem that this would drag in many modules at start-up? --000000000000cfc04c0579729778 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Oct 30, 2018 at 7:21 AM Mark H Weaver <mhw@netris.org> wrote:
Hi Mikael,

Mikael Djurfeldt <mikael@djurfeldt.com> writes:

> On Tue, Oct 30, 2018 at 1:26 AM Mark H Weaver <mhw@netris.org> wrote:
>
>=C2=A0 Mikael Djurfeldt <mikael@djurfeldt.com> writes:
>
>=C2=A0 > The interface of (value-history) would instead have a lazy-= binder
>=C2=A0 > which provides a syntax transformer for every $... actually= being
>=C2=A0 > used. The $... identifier would expand into a list-ref into= the value
>=C2=A0 > history.
>
>=C2=A0 A few more suggestions:
>
>=C2=A0 If I write (define (foo x) (+ $$0 x)) at the repl, then I expect= 'foo'
>=C2=A0 to continue to refer to the same entry in the value history, eve= n after
>=C2=A0 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.=C2=A0 I very often write procedures that reference values from the value history.=C2=A0 In almost every case I can think of, I=
want those references to continue to refer to the same value in the
future.=C2=A0 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?
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?

No, I think that if we implement backward references,= then we should be able to pick any value. One or two would be frustrating = in many situations.

Another possible syntax would = be that $-1 refers to the most recent value, and then we could have $-2, $-= 3, etc. It would all be consistent if value history started out with $0 =3D= ... . Dunno.
=C2=A0
> 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.=C2=A0 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<= br> REPLs.=C2=A0 Each REPL should have its own history, I think.=C2=A0 Modern G= uile
offers REPL servers, which listen for network connections and spawn a
new REPL thread for every incoming connection.=C2=A0 We also have cooperati= ve
REPL servers that enable multiple REPLs within a single thread using
cooperative threading, to avoid thread safety issues.=C2=A0 Those require a=
procedure to be called periodically, and are intended for
single-threaded programs based on event loops.=C2=A0 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?

You raise an importa= nt issue.

Since every REPL runs with its own dynam= ic state, perhaps a par of fluids would help?

Ive = noticed Ludovic's (ice-9 vlist) which, as a functional datastructure, w= ould mesh well with a fluid. At the same time it at least partially address= es your concern regarding efficiency since at least the most recent history= values would be accessed at O(1).

So, history wou= ld be stored as a vlist in a fluid and $... references would expand to vlis= t-ref.

What do you think?

Is it a problem that this would drag in many modules at start-up?
--000000000000cfc04c0579729778--