From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Can't M-x compile-defun `edebug' because dynamic variables are falsely taken as lexical. Date: Thu, 13 Feb 2020 21:24:17 -0500 Message-ID: References: <20170103141444.GA4649@acm.fritz.box> <20170103213228.GB2085@acm.fritz.box> <20170104133948.GA7373@acm.fritz.box> <20170104200458.GA2052@acm.fritz.box> <29855ded-8607-4132-a80f-3204c06d74d9@default> <256f068f-5a0a-4127-aa7c-633eae24f15f@default> <837a062d-8fb0-4b41-bc53-d96a166263a4@default> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="105333"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Alan Mackenzie , emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Feb 14 03:24:56 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1j2Qf1-000RIe-Ta for ged-emacs-devel@m.gmane-mx.org; Fri, 14 Feb 2020 03:24:55 +0100 Original-Received: from localhost ([::1]:33850 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j2Qf0-00044i-Vu for ged-emacs-devel@m.gmane-mx.org; Thu, 13 Feb 2020 21:24:55 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56130) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j2QeX-0003fw-O2 for emacs-devel@gnu.org; Thu, 13 Feb 2020 21:24:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j2QeV-0006ek-UH for emacs-devel@gnu.org; Thu, 13 Feb 2020 21:24:25 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:51093) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1j2QeV-0006cy-O1 for emacs-devel@gnu.org; Thu, 13 Feb 2020 21:24:23 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id CA878101377; Thu, 13 Feb 2020 21:24:22 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 76520100BD3; Thu, 13 Feb 2020 21:24:20 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1581647060; bh=bg3yIjSGVqVNgknWVfMObcyskoxhaUadgaGBTlPPfDw=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=ico+rJKSG831HvMoC2QALSl3SLDRhkYw2r+8RUSi7JF796UcLGWcUAnZp4sJWzBaF 6AkaXKibTwaFo1qDtQyqzBeYcKLyNcyqdRSjEjqHlrpIwzdOra9pFyut33k2h2O6QX OykVd2g0+DeEnGEj4lWPpyo6GOS/wYJ/3MaKQuChUy9xmXZVV1jWuWMmk1EWy3dvt8 X0zUxMLIqJLTxjnjxcOSO1pXEgldJnwLTTmyza3Ij168F04vyz5l1P8R54tLe2fLlS YoQph01uYZg+qUyRKUmosYAvdpZyk1tF8Ey0kgCwOedMlH86q4aq3Jrz9Pze9rFi4c ZY9nwpK4PLHGw== Original-Received: from alfajor (unknown [157.52.14.222]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 0CC82120329; Thu, 13 Feb 2020 21:24:20 -0500 (EST) In-Reply-To: <837a062d-8fb0-4b41-bc53-d96a166263a4@default> (Drew Adams's message of "Thu, 13 Feb 2020 17:07:47 -0800 (PST)") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 132.204.25.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:244933 Archived-At: > Permanently is not the opposite of locally. Instead > of "permanently", shouldn't that text say "globally"? Feel free to provide a patch that tries to clarify. Part of the issue is that (defvar VAR VAL) is just like (defvar VAR) when it's "processed" by the byte-compiler: it won't affect bindings of VAR everywhere but only within the corresponding lexical scope. But when (defvar VAR VAL) is *executed* then it subsequently will affect all interpreted code and all the code that is subsequently compiled in that same Emacs session, whereas *executing* (defvar VAR VAL) only affects the code subsequently interpreted, and only within the current lexical scope. > I think what you mean there is what Common Lisp calls > "indefinite scope" - there are no limits on the scope > of a special variable, i.e., _where_ it can be > referenced. That sounds about right, yes. > ... the statement that "The variable is marked as 'special', meaning > that it should _always_ be dynamically bound" I'm not very happy with this statement, indeed: "always" isn't quite right. >> if @var{value} is omitted then the variable is only >> marked special locally (i.e.@: within the current >> lexical scope, or file if at the top-level). > This feature doesn't exist in Common Lisp, AFAIK. AFAIK, in CL you can get something similar with (declare (special foo)). > In CL, `defvar' always proclaims the variable special, > whether or not an initial value is provided. Indeed, Elisp is slightly different in this respect. > And I think that for CL, a variable that is ever > special is always and everywhere special, i.e., in > all contexts. It's always bound dynamically. In Common Lisp (list (lambda (x) (let ((y x)) (declare (special y)) (lambda (z) (+ y z)))) (lambda (x) (let ((y x)) (lambda (z) (+ y z))))) gives you two functions that don't behave the same because the `y` binding in the first is dynamically scoped whereas that same `y` binding is statically scoped in the second. > When you say "Same for us", I'm guessing maybe you're interpreting > what I wrote with "special" having your special ;-) interpretation as > being context-dependent: No, I'm saying that there's more to it than just either always or never. E.g. in Common Lisp after the system has *compiled* a chunk of code with (defvar VAR ...), VAR may or may not be special (i.e. the `defvar` must have affected the compiled code, but not necessarily the state of the system that compiled the file). [ In Elisp, the situation is somewhat similar, tho a bit less undefined. ] >> Does Common Lisp offer something like `special-variable-p`? > Not that I know of. Indeed. And for good reasons: being a function it's hard to make it provide the kind of semantic you expect from it, given the complexity and scope-sensitivity of "specialness". > But it also doesn't use `defvar' with and without second arg to > declare specialness. That's just a superficial syntactic difference. Maybe the slightly deeper difference is that Common Lisp doesn't have a way to say "all bindings of VAR under the current scope should be dynamic", like (defvar VAR) does. Instead it has (declare (special VAR)) which only talks about one particular binding. But both Elisp's `defvar` and CL's `declare` introduce the same issue that specialness is not all-or-nothing and that a plain function like `special-variable-p` can't give quite the answer we'd ideally want. Stefan