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: Rant - Elisp terminology is deceptive Date: Mon, 26 Jan 2015 03:52:17 +0000 Message-ID: <3WlAOmGl4RQBG09UiGavcwZwdqzrac0HS8Fc6alaxbN@local> References: <87k30b42c9.fsf@fencepost.gnu.org> <87oapn43uc.fsf@fencepost.gnu.org> 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 1422244413 14121 80.91.229.3 (26 Jan 2015 03:53:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 26 Jan 2015 03:53:33 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 26 04:53:33 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 1YFajx-0000D6-PI for ged-emacs-devel@m.gmane.org; Mon, 26 Jan 2015 04:53:30 +0100 Original-Received: from localhost ([::1]:39897 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YFajx-0002OJ-28 for ged-emacs-devel@m.gmane.org; Sun, 25 Jan 2015 22:53:29 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51927) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YFajt-0002OD-1A for emacs-devel@gnu.org; Sun, 25 Jan 2015 22:53:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YFajr-00064X-QT for emacs-devel@gnu.org; Sun, 25 Jan 2015 22:53:24 -0500 Original-Received: from relay4-d.mail.gandi.net ([2001:4b98:c:538::196]:55776) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YFajn-000648-OZ; Sun, 25 Jan 2015 22:53:20 -0500 Original-Received: from mfilter13-d.gandi.net (mfilter13-d.gandi.net [217.70.178.141]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id EE9C9172074; Mon, 26 Jan 2015 04:53:18 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter13-d.gandi.net Original-Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter13-d.gandi.net (mfilter13-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id QH2uLyAuUafT; Mon, 26 Jan 2015 04:53:17 +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 relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 1C216172070; Mon, 26 Jan 2015 04:53:15 +0100 (CET) In-Reply-To: <87oapn43uc.fsf@fencepost.gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4b98:c:538::196 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:181771 Archived-At: David Kastrup wrote: > Closures nest. Buffers don't. If you define nesting to be a required attribute of environments, then of= course, by definition, things that don't nest aren't environments. But i= t seems strange to define them that way. Maybe this is a basic computer s= cience truth I just missed. How about a language that provides only global variables? No locals of an= y kind. Would you say that its global =E2=80=9Fenvironment=E2=80=9D isn't= really an environment, because there's nothing to nest it in or nest in = it? For Elisp, although buffers' environments can't nest in other buffers' en= vironments, they do nest in something (the global environment, which I gu= ess you would call the =E2=8C=9Cdefault environment=E2=8C=9D), and there = are environments (of closures) that can nest in them. You can have a glob= al variable, shadowed by a buffer-local, shadowed by a closure-local. > Closures are part of a lexical environment. Buffers aren't. An environment can only have one binding for a particular name, which mea= ns that if the name =E2=8C=9Cshift-select-mode=E2=8C=9D can be bound to t= in the global/default environment, to nil in a buffer-local environment,= and to 'bar in a closure's environment, then those are necessarily three= different environments. If there weren't, then there couldn't simultaneo= usly be three bindings for the same name. Even if you have only global scope and dynamic extent, not lexical scope = and closures, every =C2=ABlet=C2=BB still creates a new environment at ru= ntime that nests both in the global environment and in every earlier =C2=AB= let=C2=BB being evaluated, and each variable bound in an environment shad= ows every variable with the same name in every outer environment. Even if= this is implemented by storing the current environment in place of outer= ones and pushing the latter onto a stack, the effect is the same. I think you're using =E2=80=9Fenvironment=E2=80=9D to mean something diff= erent than I am. Maybe I'm using it wrong. > --shift-select-mode-- is a generated symbol (with value 'bar) not in an= y > way related to the global variable shift-select-mode. It has a relationship to the global variable that a buffer-local variable= also has: it shadows it. > Again, the buffer does not provide scoping. IIUC, you mean that lexically, a buffer-local variable is defined in the = global scope. But my point is that its runtime instances aren't in the gl= obal environment; they're in buffers' environments. If there were only on= e environment, then there could be only one instance of the variable, mea= ning different buffers couldn't have different values for it. If I do (setq-default shift-select-mode nil), and in three buffers I do (setq-local shift-select-mode (random)), how many runtime variables do I = have? Do you say I have only one or two? If so, which environment(s) is i= t bound in? I say I have four, each in a separate environment. David Kastrup wrote in a different message: >> Look what happened when I proposed changing the names of set-default, >> setq-default, and default-value. They're misleading, > > No, they aren't, but you are not willing to hear any explanation in > conflict with your preconceptions. Of course, this misleadingness is a matter of perception. The names are c= ertainly misleading to me, despite your explanation. I thought everybody = would perceive them as misleading, but obviously I was wrong about that, = since you don't. At least Stephen and Eli only said the names are too old= to change, not that they're not misleading. If I'm just part of a minority that fails to understand that =E2=8C=9Cdef= ault=E2=8C=9D is the most sensible term for the Emacs environment whose v= ariables don't shadow variables in any other environment, then of course = the term shouldn't be changed. But if I'm part of a majority that fails to understand, then resistance i= s futile. You will be assimilated. > I have my problems seeing how "Contents of address register" and > "Contents of decrement register" are accurate concerning the current > implementations. Of course, those terms are not accurate at all now. But they used to be. = That's why I said they're archaic. > In their _archaic_ sense, those terms are not accurate. Probably you mean the same thing I do, just phrased the opposite. > fboundp is sort of an archaic feature of the language. But given the feature, the name isn't archaic. If I had to choose a name = today for that function, =E2=8C=9Cfboundp=E2=8C=9D would be a fine choice= . That's all I meant. > there are regularly > scheduled shouting events under the title of "standards committee". > > With regard to Emacs Lisp, we don't have such official events. Isn't that what emacs-devel is for? ;-)