[Top][All Lists]

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

Emacs variables (was: Bug in eval-string?)

From: Matthias Koeppe
Subject: Emacs variables (was: Bug in eval-string?)
Date: Tue, 27 Aug 2002 16:18:12 +0200
User-agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1.80 (sparc-sun-solaris2.7)

Marius Vollmer <address@hidden> writes:

>[abstract part of the discussion snipped]
> Matthias Koeppe <address@hidden> writes:
>> The only reason why I would be interested in a Guile-based
>> implementation of Emacs is the hope for a clean, thread-safe Lisp
>> engine, which would allow for a multi-threaded Emacs.  We can't reach
>> this goal if we copy all the inherently single-threaded stuff
>> (swapping in and out values, as with FLUID-LET) from the Emacs Lisp
>> engine into Guile.
> I still don't see how fluid-let ruins multi-threaded applications.
> The current buffer needs to be thread-local, but code like
>    (fluid-let ((case-fold-search #f))
>       ...)
> would still need to be used.  

This example illustrates the problem with FLUID-LET, in fact.  From
the syntactic variations you gave below I deduce that you want to
translate the common Emacs Lisp construction

          (let ((case-fold-search nil)) 

to a FLUID-LET that temporarily sets the buffer-local value of the
variable CASE-FOLD-SEARCH to false.  

But in a multi-threaded Emacs I want to have the possibility of having
a user-interaction thread, where I (the user) can set CASE-FOLD-SEARCH
in a buffer to some value I like, and some other thread that scans the
same buffer (for instance, for creating an index) using
CASE-FOLD-SEARCH = nil.  Of course the other thread cannot temporarily
set the buffer-local value of CASE-FOLD-SEARCH to its liking, because
this would disturb the user interaction.  This means that FLUID-LET
cannot be used here, unless you stored the buffer-local value of a
variable in fluids.

However, in other cases a thread _wants_ to make a mutation of a
buffer-local variable.  Therefore, we cannot simply store all
buffer-local values in fluids.

The point is that Emacs Lisp's dynamically-binding LET binds a
_symbol_ to a fresh _location_ in its dynamic environment.  This is
semantically very different from a value-swapping FLUID-LET (in a
multithreaded environment), no matter to which generalized location
FLUID-LET is applied.  This is not simply about the "exposition of
Emacs variables to Scheme".  It's about the implementation of dynamic
scoping in a multithreaded environment.

The dynamic environment, of course, is thread-local, so it can be
implemented in Guile with a fluid.  See my pseudocode in my previous


Matthias Köppe --

reply via email to

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