From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Rant - Elisp terminology is deceptive Date: Sun, 25 Jan 2015 10:16:59 +0100 Message-ID: <87oapn43uc.fsf@fencepost.gnu.org> References: <87vbjw4f0z.fsf@fencepost.gnu.org> <4FMMk0pLUrXu73HsWAPNrK3cw3LlAT0PayRH8aoS4es@local> 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 1422177463 28788 80.91.229.3 (25 Jan 2015 09:17:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 25 Jan 2015 09:17:43 +0000 (UTC) Cc: emacs-devel@gnu.org To: Kelly Dean Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 25 10:17:42 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 1YFJKA-0004e0-Ni for ged-emacs-devel@m.gmane.org; Sun, 25 Jan 2015 10:17:42 +0100 Original-Received: from localhost ([::1]:37203 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YFJK9-0003xu-U1 for ged-emacs-devel@m.gmane.org; Sun, 25 Jan 2015 04:17:41 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38711) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YFJK6-0003xd-02 for emacs-devel@gnu.org; Sun, 25 Jan 2015 04:17:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YFJK4-00046r-P4 for emacs-devel@gnu.org; Sun, 25 Jan 2015 04:17:37 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51863) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YFJK4-00046n-MU for emacs-devel@gnu.org; Sun, 25 Jan 2015 04:17:36 -0500 Original-Received: from localhost ([127.0.0.1]:59038 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YFJK4-00071q-Aw; Sun, 25 Jan 2015 04:17:36 -0500 Original-Received: by lola (Postfix, from userid 1000) id 39908DF31C; Sun, 25 Jan 2015 10:16:59 +0100 (CET) In-Reply-To: <4FMMk0pLUrXu73HsWAPNrK3cw3LlAT0PayRH8aoS4es@local> (Kelly Dean's message of "Sat, 24 Jan 2015 23:24:49 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:181741 Archived-At: Kelly Dean writes: > David Kastrup wrote: >> A buffer does not have an "environment". > > What do you call the thing that lists the bindings of buffer-local > variables to values? The standard term for a list of bindings of > variables to values that's used for resolving variable references, > both in Lisp and elsewhere, is =E2=80=9Fenvironment=E2=80=9D. > >> It has a list of global variable values >> to substitute whenever it is made current. > > You mean like a closure can have? (A closure's environment can also have = variables with names that aren't names of global variables, but that's not = the point here.) > (setq foo > (lexical-let ((shift-select-mode 'bar)) > (lambda () shift-select-mode))) > (funcall foo) =E2=86=92 bar Closures nest. Buffers don't. And there always is one current buffer. Closures are part of a lexical environment. Buffers aren't. >> buffer-local variables _are_ buffer-local versions of _global_ >> variables. > > shift-select-mode above is a closure-local version of a global > variable. Not at all. It is not related to the global variable in any way. If you do (disassemble (byte-compile foo)) you get byte code: args: (&rest --cl-rest--) 0 constant apply 1 constant args: (G42200) 0 varref G42200 1 symbol-value=20 2 return=20=20=20=20 2 constant --shift-select-mode-- 3 varref --cl-rest-- 4 call 3 5 return=09=20=20 which is rather awful. But the salient point is that --shift-select-mode-- is a generated symbol (with value 'bar) not in any way related to the global variable shift-select-mode. >> With setq-default you are not setting >> a value that is in any manner more or less global than a buffer-local >> setting. > > setq-default sets the global variable, which is visible in other > buffers (unless they shadow it with their own buffer-locals). > A buffer-local variable is not visible in other buffers. The default value and the global value are part of the same symbol and accessed with different commands. > I don't know how buffer-locals are implemented internally, but from a > user's (and Elisp programmer's) point of view, a buffer has an > environment with variables that shadow global variables. Again, the buffer does not provide scoping. It is the setting of (current-buffer) that decides which buffer-local values are active. > If the value of each variable in that environment is stored as part of > the structure that stores the value of the same-named global variable > rather than being stored in a separate list of bindings for the > environment, that's irrelevant. The effect is the same. There is no nesting of scopes involved here. At any given time, only one buffer's global variable are active. That is similar to global static variables in C: they are not nested. Instead, one compilation unit at a time may provide a value. C does not have defaults for global static variables: it is an error to declare the same name as global external and global static. Elisp, in contrast, provides two value slots for that purpose. > The help system agrees with me. It doesn't call buffer-locals > =E2=80=9Fglobal=E2=80=9D. It _contrasts_ buffer-locals and > globals. E.g. describe-variable for mark-active tells me: mark-active > is a variable defined in `buffer.c'. Its value is t Local in buffer > *Help*; global value is nil It does not seem like a good idea to spread the confusion, however. --=20 David Kastrup