From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kelly Dean Newsgroups: gmane.emacs.devel Subject: Re: The purpose of makunbound Date: Fri, 20 Feb 2015 09:35:30 +0000 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1424425050 2470 80.91.229.3 (20 Feb 2015 09:37:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 20 Feb 2015 09:37:30 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 20 10:37:20 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YOk1Q-00035B-BU for ged-emacs-devel@m.gmane.org; Fri, 20 Feb 2015 10:37:20 +0100 Original-Received: from localhost ([::1]:59657 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YOk1P-00025c-Pt for ged-emacs-devel@m.gmane.org; Fri, 20 Feb 2015 04:37:19 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50950) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YOk1D-00024f-Gk for emacs-devel@gnu.org; Fri, 20 Feb 2015 04:37:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YOk19-0006TV-Bm for emacs-devel@gnu.org; Fri, 20 Feb 2015 04:37:07 -0500 Original-Received: from relay5-d.mail.gandi.net ([2001:4b98:c:538::197]:36305) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YOk19-0006SE-5d for emacs-devel@gnu.org; Fri, 20 Feb 2015 04:37:03 -0500 Original-Received: from mfilter12-d.gandi.net (mfilter12-d.gandi.net [217.70.178.129]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 0A91341C0D0; Fri, 20 Feb 2015 10:37:02 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter12-d.gandi.net Original-Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter12-d.gandi.net (mfilter12-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id U5+hZzwxuVBi; Fri, 20 Feb 2015 10:37:00 +0100 (CET) X-Originating-IP: 66.220.3.179 Original-Received: from localhost (gm179.geneticmail.com [66.220.3.179]) (Authenticated sender: kelly@prtime.org) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 6E9D941C07D; Fri, 20 Feb 2015 10:36:53 +0100 (CET) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4b98:c:538::197 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:183322 Archived-At: Stefan Monnier wrote: > Ah, I think I understand a bit better. I think treating "void" as an > event is the error: it's a state. OTOH, the "revert to previous > state" done at the end of `let' is indeed an event. I'm not treating void as an event. Of course it's a state. I'm treating =C2= =ABset the state to void=C2=BB as an event, and =C2=ABexit let=C2=BB as a= n event, and my first point is that since they're different events with d= ifferent resultant states, different terminology should be used for them. My second point is that if makunbound didn't work for let-bound or buffer= -local variables, then the void state could never shadow a non-void state= , which means an =C2=ABexit let=C2=BB event could never change a void sta= te to a non-void state. Therefore a =C2=ABset the state to void=C2=BB eve= nt would be indistinguishable from an =C2=ABexit let=C2=BB event in which= no non-void state had been shadowed, and of course there's no need for d= ifferent terminology for indistinguishable events. In contrast, with maku= nbound's current behavior, those two events are distinguishable: the firs= t one leaves open the possibility that a subsequent =C2=ABexit let=C2=BB = event will produce a non-void state, but the second one doesn't. > I don't see "unbind" used anywhere in the description of what `let' > does, nor is it a term that I've heard used (other than by yourself) to > refer to what happens at the end of a "let". The definition of =C2=ABlet=C2=BB in eval.c calls the function =C2=ABunbi= nd_to=C2=BB at the end. Also see the Emacs 24.4 Elisp manual: (elisp) Catch and Throw (section 10.5.1): =E2=8C=9CExecuting `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=E2=8C=9D (elisp) Named Features (section 15.7): =E2=8C=9CLoading a library while its variables are let-bound can have unintended consequences, namely the variables becoming unbound after the let exits.=E2=8C=9D (elisp) Warning Variables (section 37.5.2): =E2=8C=9CPrograms 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.=E2=8C=9D (elisp) Intro to Buffer-Local (section 11.10.1): =E2=8C=9Cif you exit the `let' while still in the other buffer, you won't see the unbinding occur=E2=8C=9D