From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Can't M-x compile-defun `edebug' because dynamic variables are falsely taken as lexical. Date: Wed, 4 Jan 2017 20:04:58 +0000 Message-ID: <20170104200458.GA2052@acm.fritz.box> References: <20170103141444.GA4649@acm.fritz.box> <20170103213228.GB2085@acm.fritz.box> <20170104133948.GA7373@acm.fritz.box> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1483560466 11158 195.159.176.226 (4 Jan 2017 20:07:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 4 Jan 2017 20:07:46 +0000 (UTC) User-Agent: Mutt/1.5.24 (2015-08-30) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 04 21:07:43 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cOrqS-0001fO-HK for ged-emacs-devel@m.gmane.org; Wed, 04 Jan 2017 21:07:36 +0100 Original-Received: from localhost ([::1]:41299 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cOrqW-0004Hd-EN for ged-emacs-devel@m.gmane.org; Wed, 04 Jan 2017 15:07:40 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39862) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cOroG-0003Da-9z for emacs-devel@gnu.org; Wed, 04 Jan 2017 15:05:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cOroC-0001Dl-B1 for emacs-devel@gnu.org; Wed, 04 Jan 2017 15:05:20 -0500 Original-Received: from ocolin.muc.de ([193.149.48.4]:59143 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1cOroC-0001DC-0j for emacs-devel@gnu.org; Wed, 04 Jan 2017 15:05:16 -0500 Original-Received: (qmail 38731 invoked by uid 3782); 4 Jan 2017 20:05:13 -0000 Original-Received: from acm.muc.de (p548C6D63.dip0.t-ipconnect.de [84.140.109.99]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 04 Jan 2017 21:05:13 +0100 Original-Received: (qmail 1351 invoked by uid 1000); 4 Jan 2017 20:04:58 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.4 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:211108 Archived-At: Hello, Stefan On Wed, Jan 04, 2017 at 10:23:16AM -0500, Stefan Monnier wrote: > > Ouch! There seems to be a clash between symbols (which are global, > > dynamic) and lexical variables (which are local and "invisible"): the > > only way to mark a variable as lexical is at the global level. > Yes, there are some subtleties there. The main issue is that every > occurrence of an identifier, whether a binding occurrence or a "use" can > be lexical or dynamic, but we don't want the coders to have to > constantly specify which uses and which bindings are lexical and which > are dynamic. So we offer ways to "mark" symbols are "this one uses > dynamic scoping". There are 2 such ways: > - *Evaluation* of (defvar VAR VAL . REST) marks this variable as being > dynamically scoped in all the code that will be compiled in this session. > - *Compilation* of (defvar VAR . REST) marks this variable as being > dynamically scoped in the current compilation unit. > > (vi) e (special-variable-p 'edebug-breakpoints). > > This last returns nil. This suggests edebug-breakpoints has been bound > > as a lexical variable, rather than a dynamic one. (There is a defvar > > for it earlier in the file.) This is surely not right. > special-variable-p only indicates if (defvar VAR VAL . REST) was evaluated. So it would seem. There is a bug in the elisp manual, which says that a variable being declared by defvar will cause special-variable-p to return t for it. The doc string looks right, though far from helpful for anybody who doesn't already know variable binding inside out, and even a bit cryptic for those who do. special-variable-p would appear to be a near useless function, since it doesn't do what it's name says. "Defining Variables" in the elisp manual states that "(defvar foo)" makes foo a special variable; yet "(special-variable-p 'foo)" returns nil. This has got to be a bug, of some sort. There appears to be no way of checking whether a variable's binding is (or will be) lexical. I can foresee quite a bit of confusion happening over all this, if it hasn't happened already. Am I missing something, or is this all really as incoherent as it appears to me? > Stefan -- Alan Mackenzie (Nuremberg, Germany).