Re: Emacs Lisp and Guile

[Marius Vollmer]

Richard Stallman <address@hidden> writes:

>     Right now, a variable is a strictly passive data container.  You can't
>     intercept accesses to it.  A variable reference is a direct reference
>     to memory, not a function call.  We would have to change this model to
>     also allow 'active' variables that can run arbitrary code when they
>     are accessed.
> 
> That is not what I am suggesting.  Variables in Emacs do not run
> arbitrary code when accessed; I think that would be a misguided
> feature.  However, Emacs enables the value to reside in various places
> besides the symbol itself.

I think we might agree anyway: from a general, low-level Scheme
implementation point of view, Elisp variables require 'arbitrary' code
to be run when they are accessed.  From the Elisp point of view this
code isn't arbitrary at all, it is just the code that is needed to
implement the desired behavior of Elisp variables.  To the Elisp
programmer, variables are passive data containers, but to the Scheme
implementation, they are 'active'.

Thus, allowing 'active' variables in Guile would be a way to implement
the behavior of Elisp variables.  The active variables would not need
to be completely general; they could be restricted to just the set of
features that are needed for Elisp variables (like forwarding to C
variables).  But I don't think that would be an advantage.  They would
still be different from ordinary Scheme variables, but not as useful
as they might be.  If I remember correctly, TCL can sent out
notifications when the value of a variable changes.  This feature
could be implemented on top of the general active variables without
having to change the low-level Guile execution model.  It might not be
implementable with just the Elisp behavior of variables.

But there is also the question of how to present active variables to
Scheme code, once we have them.  Since passive variables are a special
case of active variables, we can just let all variables be active
variables and get a very consistent system.

But I think it is highly desirable to be able to distinguish between
passive variables and active ones at compile time.  We do have to
distinguish between functions and macros already at compile time, so
this would not be an entirely new concept.  We also will want to
identify calls to certain functions at compile time so that they can
be optimized.  Since telling passive variables from active variables
is merely an optimization, we can put it in the latter category.

> A similar feature in Guile would be useful for many sorts of
> application programs.

Yes.