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

[Matthias Koeppe <mkoeppe@mail.Math.Uni-Magdeburg.De>]

Marius Vollmer <mvo@zagadka.ping.de> writes:

>[abstract part of the discussion snipped]
>
> Matthias Koeppe <mkoeppe@mail.Math.Uni-Magdeburg.De> 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)) 
            ...CODE...)

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
message.

Regards,

-- 
Matthias Köppe -- http://www.math.uni-magdeburg.de/~mkoeppe


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel