From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Drew Adams 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 17:07:47 -0800 (PST) Message-ID: <837a062d-8fb0-4b41-bc53-d96a166263a4@default> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="49085"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Alan Mackenzie , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Feb 14 02:10:43 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 1j2PVD-000Cfe-58 for ged-emacs-devel@m.gmane-mx.org; Fri, 14 Feb 2020 02:10:43 +0100 Original-Received: from localhost ([::1]:33438 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j2PVC-0004Or-7w for ged-emacs-devel@m.gmane-mx.org; Thu, 13 Feb 2020 20:10:42 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42344) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j2PUb-0003ml-IK for emacs-devel@gnu.org; Thu, 13 Feb 2020 20:10:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j2PUZ-0007ic-T0 for emacs-devel@gnu.org; Thu, 13 Feb 2020 20:10:05 -0500 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:44412) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1j2PUZ-0007bR-LM for emacs-devel@gnu.org; Thu, 13 Feb 2020 20:10:03 -0500 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 01E1323X119377; Fri, 14 Feb 2020 01:09:54 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=1Ppo6J3XEGJ/53n3S2gT+BPN/PV6mAZEfsM4UyXoM4k=; b=QV9b/4Pw2o8mrNt8cDbKhONvj191/L5aUQePSumUqBhudTJPIKljib2o49LaIN+dypEN 3nL44u2nqR8d7VnDvEeXA3PoUd+j6kADp6J2jNoj0QIH6zGV69W/m2mAtjBfNWCJ5Wxv dZmKBf6PW1E4xk0nbbeJXLhPilkhMJ8Qsfhhbn0YWL928MHEh2h6XQiC2PGulEGB4R3i 9wz8i2xk88Py026kVAcYoUu7PUawfwhM44U3Ir6ha1iwYbFFTxgK4EQ4GaOTdMh2o8Vu R9bYb0KcEbiIndyqeON7Ask0G3wMB1VpZZ4KnT5MB14RaJxjIvtaEPd5poL5hJZgK87h Pg== Original-Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by aserp2120.oracle.com with ESMTP id 2y2jx6pcgj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 14 Feb 2020 01:09:54 +0000 Original-Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 01E13lpk005385; Fri, 14 Feb 2020 01:07:53 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3020.oracle.com with ESMTP id 2y4k9k5ucw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 14 Feb 2020 01:07:53 +0000 Original-Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 01E17o8C018885; Fri, 14 Feb 2020 01:07:52 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4954.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9530 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 suspectscore=0 spamscore=0 adultscore=0 bulkscore=0 phishscore=0 malwarescore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002140005 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9530 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 malwarescore=0 priorityscore=1501 adultscore=0 phishscore=0 impostorscore=0 spamscore=0 bulkscore=0 lowpriorityscore=0 mlxscore=0 suspectscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002140005 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 141.146.126.78 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:244931 Archived-At: > > But I'm afraid I don't know what a permanent versus > > temporary special variable is. And I haven't found > > anything in the doc that has helped me with that. >=20 > It's the term used in the part that describes `defvar`: >=20 > Note that specifying a value, even @code{nil}, > marks the variable as special permanently. Thanks. [FWIW, I'm no expert in any of this. I'm just trying (1) to understand what the Emacs story is about this and (2) to reconcile that with what I think about the Common Lisp story about it. Limited understanding of both, no doubt. Also, I'm not arguing for any change, including a realignment with CL, if there is in fact a difference. I just want the doc to be make sense and be clear about what Emacs does. So far, it doesn't seem clear to me.] ____ Permanently is not the opposite of locally. Instead of "permanently", shouldn't that text say "globally"? 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. (As contrasted with "indefinite extent", which is what lexical bindings provide - no limit on _when_ the var can be referenced - the binding can last as long as there is still some reference to the variable.) If you said "globally" then that text would no longer seem to directly contradict the statement that "The variable is marked as 'special', meaning that it should _always_ be dynamically bound", which is in the very same node, `Defining Variables'. But although not seeming to directly contradict, even that wouldn't really be right, I think. More correct would be to say "'special', meaning that it should be bound dynamically _everywhere_". Everywhere, not always. Dynamic binding, i.e., the binding of a special var, is indefinite with respect to _where_ (it's global) - what CL calls "indefinite scope". And it's dynamic with respect to _when_ (how long) - what CL calls "dynamic extent". Continuing... > 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. =20 In CL, `(defvar foo)' _proclaims_ `foo' to be special, just like `(proclaim (special foo))', and that means that it's special _everywhere_. In CL, `defvar' always proclaims the variable special, whether or not an initial value is provided. Without an initial value the variable has no global value and it's called "unbound". > > AFAIK, in Common Lisp a variable is either special > > or it's not. If it is then its binding by `let' > > is dynamic, and if it's not then its let-binding > > is lexical. (No?) >=20 > Same for us. I don't see that, so far. I think maybe you're saying (and perhaps the doc is saying) that a var that is not bound lexically in some particular context is special _in that context_ (not everywhere), and that the same variable can be bound either lexically or dynamically. 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. 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: "If it is [special] then its binding by `let' is dynamic, and if it's not [special] then its let-binding is lexical." Am I guessing right wrt your interpretation of "special"? For you (and thus Emacs terminology), can a var be sometimes special and sometimes not? I don't think that's the case for the way CL uses "special variable". However, CL does say that about a given _name_ of a variable. The same name can refer in some places to a special var and in other places to a lexical var. This is what CLTL says: At any given time either or both kinds of variable with the same name may have a current value. Which of the two kinds of variable is referred to when a symbol is evaluated depends on the context of the evaluation. The general rule is that if the symbol occurs textually within a program construct that creates a _binding_ for a variable of the same name, then the reference is to the variable specified by the binding; if no such program construct textually contains the reference, then it is taken to refer to the special variable of that name. IOW, there can be a special variable `foo' and one or more lexical variables `foo'. They have the same name but they're different variables. I think the terminology you're using would say that it's the same variable, and it's sometimes, or in some places, special and at other times, or in other places, lexical. > Does Common Lisp offer something like `special-variable-p`? Not that I know of. But it also doesn't use `defvar' with and without second arg to declare specialness. `defvar' always declares specialness (proclaims, actually).