From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Didier Verna Newsgroups: gmane.emacs.devel Subject: Re: Possible defvar bug Date: Mon, 18 Feb 2013 17:19:10 +0100 Message-ID: References: <87d2vxr8h6.fsf@thinkpad.tsdh.de> <87obfhy8zc.fsf@gmail.com> <20130218150954.GA4583@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1361206483 382 80.91.229.3 (18 Feb 2013 16:54:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 18 Feb 2013 16:54:43 +0000 (UTC) Cc: Jambunathan K , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 18 17:55:05 2013 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 1U7Tzb-00039c-3m for ged-emacs-devel@m.gmane.org; Mon, 18 Feb 2013 17:55:03 +0100 Original-Received: from localhost ([::1]:49770 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U7TzH-0001Fz-6L for ged-emacs-devel@m.gmane.org; Mon, 18 Feb 2013 11:54:43 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:51559) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U7TzC-0001FE-Ml for emacs-devel@gnu.org; Mon, 18 Feb 2013 11:54:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U7Tz5-000764-5A for emacs-devel@gnu.org; Mon, 18 Feb 2013 11:54:38 -0500 Original-Received: from sao-paulo.lrde.epita.fr ([163.5.55.1]:42657 helo=uzeb.lrde.epita.fr) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U7Tz4-00075r-Uv for emacs-devel@gnu.org; Mon, 18 Feb 2013 11:54:31 -0500 Original-Received: by uzeb.lrde.epita.fr (Postfix, from userid 17030) id AB66616E1486; Mon, 18 Feb 2013 17:19:10 +0100 (CET) In-Reply-To: <20130218150954.GA4583@acm.acm> (Alan Mackenzie's message of "Mon, 18 Feb 2013 15:09:54 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEVmRzIzJhqncVoMDQmL XUfq5NwHBAS+iHJSHqwJAAACXUlEQVQ4jX2UwWrjMBCGR12VXKXYzV6DcfG1RovOWqOSJwi9Ngj0 ACLBr7//P07anlYE4+jTzPwzmrEErFjwcKdVVxtzPp/Pgu1QC5ibNjAA3AhirQQXu97BkPP7HdCd /wZj3hHUDbifFk8PUGpwyw+QFRR6K/8B03cMyBJ4ibEGL3n62h/z61kQgbr83aI1GozvBJqH32K0 ocFkOSoIoatUNbUJYPgCwUnqkAd2Jo2BlQBi6Jej995t+2ozGoK4n5Lv5kcNGSPJTcHQ0jeAQZae oP5p63pkDdvUhpxEsmF1Y33DuatQ7ZDEdN6OT7yoGD+pMjO/IVsRO113G7gsuM60QBQsPGJd3xWE Ge5HyVTbRsNYrwrK7E4tiaXF2tIA8KzNULzYLCLLMDAKn7utS5xYaBS7aJlY/YVdUorjNlZexjtI pw3AkadJHhfIHghuGsNaBRDG6xPkshLUWXICSPCF4NmI6xl8jhc4MZSmACecqkI/U653AFpxa3ar gpmHk3FqggrgMj40j7dfFlviGWZJVm9JS+LMHq0nxtMbxbkNBGd6gETgjIcO9jpVSbdnu+KG2BJL NrcTTeQi3U7z6uZIb+JvNwUFpzRj42OdYdSfP9RVLf7ETk7WmDJ3se7P501VLXZgxqeUYBAPl90d lFj7qaEc8rd6+DuU35tcrNJP43SVrs7Go0Tx5QEw5BmtdYjwxb+H1wfApE3NRBzwHUwun1t1Q8Ho OjmUiiAEJT5TbggcngoRBYl0GvSio0ZX+KLwZNAgWC+iE0gD/PAKoL683L8Y/AhhrOmrEIV/RngP zLwgGJAAAAAASUVORK5CYII= X-Face: 'Up&ZL$$IT%!YX.Z$8TnPMd'O)}ZaT9$Z^Q8EZ"WL},<}[|=O9'1X8 SSW]&.dGePRFZLtH-(U+}v-LwQ0&7; --)JfD@)h!f,#X#kL.tmiISyqhE917Z`PU-.]<$>Ym^s>QC` `_1He0X87(ZGsMt|<['bFo" X-Attribution: dvl X-Url: http://www.lrde.epita.fr/~didier X-Web: http://www.lrde.epita.fr/~didier X-Home-Page: http://www.lrde.epita.fr/~didier Mail-Copies-To: never X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 163.5.55.1 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:157139 Archived-At: Alan Mackenzie wrote: > Why would anybody want to defvar a variable inside a let binding which > also defines it, anyway? Because you're not responsible for all the code you use; only for the code you write. Consider this for instance: | ;;; foo.el | | (defvar foo-var 42) | | (defun foo-init () | ;; do a lot of stuff using foo-var | ) | | (foo-init) | | (provide 'foo) BTW, I'm not saying this is good. This is actually pretty bad but I've seen code like this. If for some reason you're not happy with the initialization value of foo-var, it makes sense to write: | (let ((foo-var 51)) | (load "foo.el")) and although this is not true, I can even understand why some people would /intuitively/ think it would also change the global init value of foo-var. > I would argue that the current behaviour _is_ what is wanted Yes, I agree. I was referring to the docstring of defvar saying "this is not what you want", but rather in the sense that "this does not do what you think it does" (typically: change globally the initial value of a defvar'ed variable). Common Lisp behaves that way too: | * (let ((foo 3)) | (declare (special foo)) | (defvar foo 1) | (print foo)) | | 3 | 3 | * foo | | debugger invoked on a UNBOUND-VARIABLE in thread | #: | The variable FOO is unbound. | | Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. | | restarts (invokable by number or by possibly-abbreviated name): | 0: [ABORT] Exit debugger, returning to top level. | | (SB-INT:SIMPLE-EVAL-IN-LEXENV FOO #) | 0] -- ELS 2013: deadline approaching! http://www.european-lisp-symposium.org Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com