Re: The purpose of makunbound

[Stefan Monnier]

> The definition of «let» in eval.c calls the function «unbind_to» at the end.

This is completely invisible to the Elisp programmer, so it's of
no importance.

> Also see the Emacs 24.4 Elisp manual:
> (elisp) Catch and Throw (section 10.5.1):
> ⌜Executing `throw' exits all Lisp constructs up to the matching
> `catch', including function calls.  When binding constructs such as
> `let' or function calls are exited in this way, the bindings are
> unbound, just as they are when these constructs exit normally⌝

This "unbound" is indeed incorrect, it should be "undone" (if anything
is "unbound" it could be the variables, but definitely not the bindings).

> (elisp) Named Features (section 15.7):
> ⌜Loading a library while its variables are let-bound can have
> unintended consequences, namely the variables becoming unbound after
> the let exits.⌝

This "becoming unbound" here really means "the variables will end up
with a Qunbound value".  BTW, the problem described in this little bit
of text has been mostly eliminated by recentish changes which made
`defvar' use the new `set-default-toplevel-value'.

> (elisp) Warning Variables (section 37.5.2):
> ⌜Programs can bind this variable to `t' to say that the next
> warning should begin a series.
> ...
> The series ends when the local binding
> is unbound and `warning-series' becomes `nil' again.⌝

Here again "unbound" should be "undone".

> (elisp) Intro to Buffer-Local (section 11.10.1):
> ⌜if you exit the `let'
> while still in the other buffer, you won't see the unbinding occur⌝

This one is admittedly a real case where "unbind" is used to mean "undo
a let binding".


        Stefan