Re: flet not undone on lisp nesting error

[pjb@informatimago.com (Pascal J. Bourguignon)]

Dan Davison <davison@stats.ox.ac.uk> writes:

> If I trigger a lisp nesting error with an infinite recursion inside a
> let and an flet binding, then the effects of the flet are not undone,
> resulting in a change of binding at the top-level. (Code below; the
> effects of the let are undone).
>
> However, if I trigger a "normal" error with (error) then both are
> undone. Is this peculiar to a circular lisp nesting error, or are there
> other classes of error upon which flet will not be undone? What is the
> idiomatic way to protect against this (other than not having infinite
> recursions in my code)? Do I have to keep copies of the original values
> for use in an unwind-protect?
>
> Dan
>
> (defun g () 'g-orig)
> (setq a 'a-orig)
>
> (defun h ()
>   (let ((a 'a-new))
>     (flet ((g () 'g-new))
>       (h))))
> (h)   ;; <-- Lisp nesting exceeds `max-lisp-eval-depth'
> (g)   ;; 'g-new ! 
> a     ;; a-orig 
>
> (defun g () 'g-orig)
> (setq a 'a-orig)
> (defun f ()
>   (let ((a 'a-new))
>     (flet ((g () 'g-new))
>       (error "Error!"))))
>
> (f)
> (g) ;; <-- 'g-orig
> a   ;; <-- 'a-orig

There is no true lexical binding in emacs, and this includes functions.
flet is a macro that simulates it with gensym'ed symbols and using
unwind-protect to restore the binding to g.  I guess that when there's
an out of stack error, the cleanup clauses of unwind-protect are not
called.  At least in your version of emacs. In my emacs-version
"23.1.1", it seems to clean up correctly (and correctly restore the
fbinding of g).


-- 
__Pascal Bourguignon__