From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.help Subject: Re: Lexical and Dynamic Scope Date: Fri, 25 Jul 2014 00:16:44 +0200 Organization: Aioe.org NNTP Server Message-ID: <878unio10z.fsf@debian.uxu> References: <87ha2bstgt.fsf@debian.uxu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1406240432 22816 80.91.229.3 (24 Jul 2014 22:20:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 24 Jul 2014 22:20:32 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Jul 25 00:20:22 2014 Return-path: Envelope-to: geh-help-gnu-emacs@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 1XARN6-00071P-0N for geh-help-gnu-emacs@m.gmane.org; Fri, 25 Jul 2014 00:20:20 +0200 Original-Received: from localhost ([::1]:52350 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XARN5-0008Es-83 for geh-help-gnu-emacs@m.gmane.org; Thu, 24 Jul 2014 18:20:19 -0400 Original-Path: usenet.stanford.edu!news.kjsl.com!feeder.erje.net!eu.feeder.erje.net!newsfeed.datemas.de!rt.uk.eu.org!aioe.org!.POSTED!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 55 Original-NNTP-Posting-Host: SIvZRMPqRkkTHAHL6NkRuw.user.speranza.aioe.org Original-X-Complaints-To: abuse@aioe.org User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-Notice: Filtered by postfilter v. 0.8.2 Cancel-Lock: sha1:BhmlJJW9yunjp1DlQpHy3H8cN40= Mail-Copies-To: never Original-Xref: usenet.stanford.edu gnu.emacs.help:206661 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:98935 Archived-At: Aurélien Aptel writes: > In dynamic scoping, each time you nest a let binding > to same symbol you add to this variable stack. When > you take the value of a symbol the value comes from > the top of the stack of this symbol. The code you sent is somewhat unclear. When the (presumed) programmer writes `my-a', it is somewhat the assumption that what is intended is the global variable, because there isn't any other `a' around. (To use global variables and return them from functions at that - but OK, it is an example to show the principle, I get that.) On the other hand, in the `let' clauses, it is far from clear that `my-a' will even be affected as in those clauses, there isn't even an `a' mentioned. I actually think that `my-a' shouldn't be affected! When I use `let', it is just to make the code easy to write, read, and change, and any code invoked from the `let' list that happens to refer to some entity with the same name shouldn't be affected. I never use `defvar', but sometimes `setq'. I use `setq' in most cases when two functions need to work on some shared file or buffer name, and I want that set in one place, where I to change it - it is not part of the interface to other functions or Emacs in general, so I would declare it restricted to those two defuns did I know a practical way. I use `let' and function parameters and I expect those to always be prioritized before any global or otherwise more distant entities with the same names. If the `let's are nested, or if they share the same name as one of the parameters - both situations I consider confusing and haven't done ever, I think - but OK, in those cases I expect the most recent mention (in the code) to hold. I don't expect `let' to affect any other code than the code in the `let' list itself, where references to the bound name will be replaced for the corresponding data. The only time I had problems with this is when I setup lambdas using bindings from `let' and function parameters. Apparently the lambdas disassociated themselves from those bindings, and instead looked for global variables. OK, I know that now so that won't happen again. -- underground experts united