Re: Emacs Lisp and Guile

[Marius Vollmer]

Richard Stallman <address@hidden> writes:

> Emacs Lisp has hundreds of dynamic variables, whose names are
> documented, that user programs examine, set, and bind.  It would be
> clumsy and impractical to hide each of these variables behind a
> separate function in Scheme.  It would be practical but clumsy to
> have a few Scheme functions for accessing and binding Lisp
> variables.  That would make Scheme very inconvenient to use,
> compared with Emacs Lisp.

Agreed.

>     What about exporting all Elisp variables to Scheme as settable
>     functions?  For example
> 
>       (set! (require-final-newline) 'ask)
> 
>     This would lead to a divergence between Scheme variables and Lisp
>     variables, but I don't think this is bad.
> 
> I think it is ugly--variables should remain variables.

I do like it.  It would also make it trivial to include the
optimizations that you talk about below.  When Elisp variables should
appear as Scheme variables we would need to implement a new kind of
variable in the core of Guile (which is no argument against doing it).

Right now, a variable is a strictly passive data container.  You can't
intercept accesses to it.  A variable reference is a direct reference
to memory, not a function call.  We would have to change this model to
also allow 'active' variables that can run arbitrary code when they
are accessed.

Whenever some code uses a variable, it can either be a passive
variable or an active variable.  It needs to treat the two cases
differently since we want to make use of the extra performance that
passive variables allow.  We would need to make sure that the
distinction between 'passive' and 'active' variables can be made at
compile time, but that should be doable as well.

This makes 'active' variables pretty similar to symbol macros, so
maybe we should just use them.

> There should be a list of current local contexts, which the user
> program can use for different purposes.  Emacs would use one for the
> current buffer's bindings, and one for the current frame's bindings.

Yes, that should be no problem.

>     I'm afraid this might turn out to be expensive and it is not a good
>     solution in a multi-threaded system.
> 
> It does not have to be expensive.  Although Emacs is not
> multi-threaded, it has an optimization for this: a variable's
> buffer-local bindings are not swapped until you try to access the
> variable.  Runnning another thread for a short time, if it does not
> access many of these variables, won't have to swap many of them.

This assumes that only one thread is running at a time.  It wouldn't
work for a machine with multiple CPUs where threads can run at the
same time and the concept of a "thread switch" does not exist.  Maybe
we don't want to care about this, which I would be very happy with.

>       Fluids
>     provide thread-local storage and dynamic-wind is used to swap values
>     in and out of these locations to establish dynamic contexts.
> 
> [...]
> Or are you saying that dynamic-wind can be used either to swap values
> in and out of a variable, or to swap values in and out of a fluid?

That's what I wanted to say.  A fluid can have one value per thread.
Dynamic-wind is then used for the dynamic contexts within a single
thread.  The fluids implement the per-thread storage without having to
rely thread switching points.

> Do fluids have an optimized mechanism like the one I described above
> for Emacs buffer-local variables?  Or does each access to a fluid look
> up the binding for the current thread?

The latter. Each thread has a vector and a fluid is implemented as an
index into that vector.  Accessing a fluid consists of finding the
current thread, finding the vector of that thread and indexing it.
(Indices that are outside the vector yield #f on read and enlarge the
vector on write.)