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

[Mikael Djurfeldt <mikael@djurfeldt.com>]

[-- Attachment #1: Type: text/plain, Size: 5255 bytes --]

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:
> >
> >  Mikael Djurfeldt <mikael@djurfeldt.com> 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?

[-- Attachment #2: Type: text/html, Size: 6679 bytes --]