[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))
...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
- Re: Bug in eval-string?, (continued)
- Re: Bug in eval-string?, Matthias Koeppe, 2002/08/09
- Re: Bug in eval-string?, Marius Vollmer, 2002/08/09
- Re: Bug in eval-string?, Matthias Koeppe, 2002/08/09
- Re: Bug in eval-string?, Marius Vollmer, 2002/08/10
- Re: Bug in eval-string?, Matthias Koeppe, 2002/08/12
- Re: Bug in eval-string?, Marius Vollmer, 2002/08/12
- Re: Bug in eval-string?, Marius Vollmer, 2002/08/14
- Re: Bug in eval-string?, Neil Jerram, 2002/08/19
- Re: Bug in eval-string?, Matthias Koeppe, 2002/08/20
- Re: Bug in eval-string?, Marius Vollmer, 2002/08/21
- Emacs variables (was: Bug in eval-string?),
Matthias Koeppe <=
- Re: Emacs variables (was: Bug in eval-string?), Marius Vollmer, 2002/08/31
Re: Bug in eval-string?, Neil Jerram, 2002/08/08