Re: Emacs Lisp and Guile

[Marius Vollmer]

Richard Stallman <address@hidden> writes:

>     There is a nearly standard macro out there called 'fluid-let' that
>     encapsulates the process completely.  For example
> 
> It looks like the right idea, though the name is confusing given that
> it does not use fluids.  Since the name fluid-let seems to be widely
> known, perhaps fluids should be given a different name.

Yes, we could do that.  We could also try to generalize the fluids so
that they can be 'local' to other contexts besides threads, like
buffers or frames.  Or, since we might use variables for buffer-local
things, we could remove fluids and use the new features of variables
to have real thread-local variables.

>     > These functions could also have code for correct interaction with
>     > buffer-local bindings and frame-local bindings.
> 
>     Does this refer to the fact that buffer-localness and frame-localness
>     are not completely independent from dynamic scoping?
> 
> The point is, if the value that was saved by fluid-let came from a
> buffer-local binding, it needs to restore that value into the same
> buffer-local binding.  If the value that was saved was from the
> buffer-global binding, fluid-let needs to restore that value into the
> buffer-global binding.  The expansion of fluid-let needs extra code
> both when saving and when restoring, to do this.

I see, thanks.

>                                                         What would need
>     to change in the above example when case-fold-search would be a
>     buffer-local variable?
> 
> I am too overloaded to try to write the code (and I'd have to restudy
> Scheme too).  Is my explanation above clear?

Yes.  (I thought you might enjoy a little bit of programming here and
there... :-)

> This needs to be done for all variables, since any might perhaps be
> made buffer-local.  fluid-let could expand into the proper code for
> this.

We should probably tackle this as the larger, more general problem of
working with arbitrary 'contexts' and variable-like 'entities'
(variables, or fluids, or settable functions, or...) that can take on
context-local values.  Let's call these entities "locations".

A particular context could then be specified by naming a location that
will hold the 'current context'.  For example, the location that
points to the current buffer is used to specify the context for
'buffer-local' locations.  The location that points to the current
thread is used for thread-local variables.

Thus, a location is characterized by its identity, and a reference to
another location that holds its context.  That reference is #f (or
nil) when the location is currently global.

The values of locations could be (conceptually) stored in a data base
that is indexed with keys that are the combination of a location and
another arbitrary value.

'Setting' a location LOC to the value VAL goes like this: when the
context reference is #f, store VAL with the key (LOC . #f).  When the
reference is not #f, 'get' the value CTXT of the referenced location
and store VAL with the key (LOC . CTXT).

'Getting' a location LOC means looking up the key (LOC . #f) when the
context reference is #f, or first 'getting' the value CTXT of the
referenced location and looking up the key (LOC . CTXT).

There would also be a way to set the context reference of a location,
of course.

fluid-let would then remember the (LOC . CTXT) key and would swap
according to that key.

With the above model, we can have buffer-local variables where the
curren-buffer variable is itself thread-local, for example.  We could
not have the situation where a variable is buffer-local in one thread
and frame-local in another (that is, where the context reference of a
location is itself stored in a location).  Maybe we can generalize the
model, or maybe we don't want to.

The real implementation can use the optimizations that Emacs currently
uses for its buffer-local etc variables.

(I like the name 'with' better instead of 'fluid-let'.  It goes with
'with-input-from-file', which sets the current-input-port in a dynamic
extent, for example.  But fluid-let is better known.)

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405