[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposal for a new (ice-9 history)

From: Mikael Djurfeldt
Subject: Re: Proposal for a new (ice-9 history)
Date: Tue, 30 Oct 2018 14:59:10 +0100

On Tue, Oct 30, 2018 at 7:21 AM Mark H Weaver <address@hidden> wrote:
Hi Mikael,

Mikael Djurfeldt <address@hidden> writes:

> On Tue, Oct 30, 2018 at 1:26 AM Mark H Weaver <address@hidden> wrote:
>  Mikael Djurfeldt <address@hidden> 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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]