Re: Emacs Lisp and Guile

[Marius Vollmer]

Richard Stallman <address@hidden> writes:

> Having now seen the R5RS description of dynamic-wind, I see it is a
> very low-level mechanism.  For the sake of using dynamic-wind for
> dynamic variable bindings, it would be convenient to have a function
> to swap in bindings and a function to swap out bindings.  Then
> when you write calls to dynamic-wind, you would call these functions,
> not manipulate bindings directly.

There is a nearly standard macro out there called 'fluid-let' that
encapsulates the process completely.  For example

  (fluid-let ((case-fold-search #f))
    (search-forward ...))

would expand to

  (let ((body (lambda () (search-forward ...)))
        (outer #f))
    (define (swap)
      (let ((t outer))
        (set! outer case-fold-search)
        (set! case-fold-search t)))
    (dynamic-wind swap body swap))

> 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?  What would need
to change in the above example when case-fold-search would be a
buffer-local variable?

Or do you intend to implement buffer-localness (etc) itself by using
the functions?  These functions would then need to run when the
current buffer changes.  But dynamic-wind does not react to changes to
the current buffer so we can't use it to run the swapping functions at
the right times, I would say.  Can you elaborate?

> Suppose that Guile could run arbitrary code before and after the
> variable reference, for effect only, and the variable reference
> itself would always occur normally.  This would not encourage people
> to use variables for jobs that ought to be done by functions, but
> would permit implementation of this optimization, and various sorts
> of forwarding.  What do you think of this idea?

I think it's very nice!  I have sent a smallish proposal to the
guile-devel list about preparing us for specially constructed
'non-dumb' variables that need to be accessed with scm_variable_ref
and scm_variable_set_x.  We can then add whatever code is needed to
these two functions and be sure that they wont be side-stepped.

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