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

[Mark H Weaver]

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?

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