Re: emacs+guile

[Ken Raeburn]

On Jan 3, 2006, at 11:10, Mikael Djurfeldt wrote:
> Emacs behavior is to a large extent controlled by the state of a set
> of global and buffer-local variables. Elisp code often uses dynamic
> binding to temporarily change some state, such as:

Yep.  Especially when (if?) it comes to a multithreaded Emacs,  
handling dynamic bindings is going to be a huge issue.  As for the  
primitives looking at those variables, that's an angle I hadn't  
thought much about.

I'm still not entirely convinced by the "Lisp and Scheme should just  
magically interoperate seamlessly" camp.  (Okay, maybe I'm  
misrepresenting the position a little.)  So if we need one function  
to provide a Lisp-y interface and another to provide a Scheme-y  
interface, presumably with one capable of being a wrapper around the  
other, I don't think it would bother me too much.  But I can't even  
share symbols between the two languages yet, even to the point of  
code in one language being able to see symbols in the other language,  
much less see them as native symbols.  So I guess there's a little  
time to figure that out.  Or for the Scheme experts to point me in  
the right direction. :-)

As you mention, it does seem like fluids would offer a way to deal  
with Lisp dynamic binding issues.  Buffer- and frame-local variables  
bother me more.  They make the variable bindings dependent on bits of  
external state, but buffers and frames probably shouldn't be the  
relevant concepts down at the basic Scheme level, it should be  
something more generic.  Hmm... did we go over this a few years ago?   
I vaguely recall a suggestion of using a procedure-with-setter for a  
Lisp variable, invoking it to get the value, which could go off and  
check for buffer-local settings etc.  Not sure how that would  
interact with dynamic bindings (or, offhand, how it's supposed to  
interact).  I should go dig through the archives sometime....

>  (let ((case-fold-search nil)))
>     (string-match ...))

New primitive, with no Lisp variable references:
(string-match-1 regexp string &optional start case-fold)
Lisp:
(defun string-match (regexp string &optional start)
  (string-match-1 regexp string start case-fold-search))
Or something...


> Possibly one could indeed use fluids if enough convenient helper
> syntax, such as some variant of fluid-let, is provided. Personally,
> I've been playing with the thought of storing state, such as
> case-fold-search, in some kind of objects representing context in
> similarity to how GWM (The Generic Window Manager) handles properties
> of X windows. Also in this case, there is a need of helper syntax. The
> advantage would be that one could avoid dynamic binding and have a
> somewhat better modularization and abstraction of states.

I'm not familiar with GWM, though it sounds like stuff I'm doing at  
work.  Sounds like a good approach.

Third-party Lisp code still has to continue to work, so to Lisp code,  
it has to look like dynamic binding of case-fold-search does the  
right thing; so, either the dynamic binding of case-fold-search or  
the execution of string-match from Lisp still needs to make the right  
thing happen.

Ken