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: Thu, 19 Feb 2015 10:45:17 +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 1424342816 32121 80.91.229.3 (19 Feb 2015 10:46:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 19 Feb 2015 10:46:56 +0000 (UTC) Cc: emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 19 11:46:45 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 1YOOd3-0007FT-FT for ged-emacs-devel@m.gmane.org; Thu, 19 Feb 2015 11:46:45 +0100 Original-Received: from localhost ([::1]:55705 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YOOd2-0003gu-Kl for ged-emacs-devel@m.gmane.org; Thu, 19 Feb 2015 05:46:44 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41799) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YOOcz-0003ge-Ei for emacs-devel@gnu.org; Thu, 19 Feb 2015 05:46:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YOOcv-0007nO-CC for emacs-devel@gnu.org; Thu, 19 Feb 2015 05:46:41 -0500 Original-Received: from relay3-d.mail.gandi.net ([2001:4b98:c:538::195]:38461) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YOOcv-0007lN-6B; Thu, 19 Feb 2015 05:46:37 -0500 Original-Received: from mfilter36-d.gandi.net (mfilter36-d.gandi.net [217.70.178.167]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 10CFEA8113; Thu, 19 Feb 2015 11:46:36 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter36-d.gandi.net Original-Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter36-d.gandi.net (mfilter36-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id SnzDzkSQ0Eew; Thu, 19 Feb 2015 11:46:34 +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 relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 60D7DA80AB; Thu, 19 Feb 2015 11:46:33 +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::195 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:183291 Archived-At: > The word "unbound" is being used in an ambiguous fashion, but once you > see past that, there is nothing strange about what's really going on. > > Maybe we should change terminology to get rid of the ambiguity. > The name 'makunbound' is the cause of it, but that is hard to change no= w. > We could at least explain it better. To get rid of the ambiguity, I propose always using the term =E2=80=9Fvoi= d=E2=80=9D for what makunbound sets, and using the =E2=80=9Fbind/unbind=E2= =80=9D terminology exclusively for the kind of binding that =C2=ABlet=C2=BB= does. Emacs already uses the term =E2=80=9Fvoid=E2=80=9D sometimes. For example= , if you try to evaluate a symbol after doing makunbound on it, then assu= ming there isn't a lexical variable of it in scope, it signals the error = =E2=8C=9Cvoid-variable=E2=8C=9D. And the docstrings for makunbound and bo= undp use that term. Consistently using it would make the code more clear. So, I propose a global search/replace in the source code of =E2=8C=9CQunb= ound=E2=8C=9D to =E2=8C=9CQvoid=E2=8C=9D. Maybe you'll think that in some= places, it really makes more sense to interpret it as =C2=ABunbound=C2=BB= , not =C2=ABvoid=C2=BB. However, that would be inconsistent, if makunboun= d is allowed to function on non-global (i.e. let-bound or buffer-local) v= ariables. To make it consistent, leave =E2=8C=9CQunbound=E2=8C=9D the way= it is, and make makunbound stop functioning on non-global variables; tha= t's what I prefer, but since nobody else does, the alternative way of bei= ng consistent is to change =E2=8C=9CQunbound=E2=8C=9D to =E2=8C=9CQvoid=E2= =8C=9D. A search-replace of =E2=8C=9Cunbound=E2=8C=9D to =E2=8C=9Cvoid=E2=8C=9D i= n the =C2=ABel=C2=BB files would also be in order, but it would break cod= e that depends on the current names, and apparently just making aliases f= or the old names isn't an acceptable solution. Currently, the Elisp code = is inconsistent; it uses =E2=80=9Fvoid=E2=80=9D in a few places, and =E2=80= =9Funbound=E2=80=9D in most others. It doesn't look like it ever uses =E2= =80=9Funbound=E2=80=9D in the sense of let-binding. In the manual, it's t= he opposite: it usually uses =E2=80=9Fvoid=E2=80=9D for the special value= , and uses =E2=80=9Funbound=E2=80=9D in the sense of let-binding in a cou= ple places. Just to be clear, the only reason there's any ambiguity in the first plac= e is because makunbound operates on non-global variables. If it didn't do= that, there would be no need for =C2=ABvoid=C2=BB as a separate concept.= (Being bound to void vs. being unbound is indistinguishable for globals,= since they can't shadow anything.) =E2=80=9FUnbound=E2=80=9D would be al= l that's needed, =E2=80=9Fvoid=E2=80=9D would just be a synonym, and the = names of makunbound and boundp would be appropriate for those functions.