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: lexical-binding is turned on in more use cases Date: Mon, 09 Mar 2020 18:05:12 -0400 Message-ID: References: <83pndo9zeb.fsf@gnu.org> <83o8t6bx2p.fsf@gnu.org> <83k13ubv3g.fsf@gnu.org> <83imjebsrh.fsf@gnu.org> <20200308193048.GB4832@ACM> <20200309202259.GA16294@ACM> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="70766"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Mar 09 23:06:04 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 1jBQXC-000IFj-HH for ged-emacs-devel@m.gmane-mx.org; Mon, 09 Mar 2020 23:06:02 +0100 Original-Received: from localhost ([::1]:50544 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jBQXB-0002kC-IK for ged-emacs-devel@m.gmane-mx.org; Mon, 09 Mar 2020 18:06:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48973) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jBQWY-0002GZ-1J for emacs-devel@gnu.org; Mon, 09 Mar 2020 18:05:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jBQWW-00021q-6c for emacs-devel@gnu.org; Mon, 09 Mar 2020 18:05:21 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:3031) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jBQWT-0001vv-H5; Mon, 09 Mar 2020 18:05:17 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 63E5844F1C6; Mon, 9 Mar 2020 18:05:16 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 429AC44F1BA; Mon, 9 Mar 2020 18:05:14 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1583791514; bh=kix0htn3/W9CLrAS0KoV1ohM5Za3MRYdaPHoJSoLqLU=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=GiKHLu3tQ4QUEPyCBWwOm4u3E5uSq3c2HN7Bd2UvYXIXB5152tHKc/Qhal8EXPzSM iXGCV5WRx/g044OuMi39e6oByV0qpLaSWTfCKsKmg1KwR3OwutI/20sybpjXOwk3Qm su7a6yXoGZt77sOtwChjbZdULWA2SDmM1P0FVFHFSukYCl0TrIuK8zQCCsfmO42x4w rMySa+8BfdfZODTn+wGUe0erlMzAXB1FnCTHw5eToi208bFL10ugZV01+QV0CTxxjo +6dcYOH946/IoqJ5KqwnmmRL1szYyXBHmB1rXi32sU14EPryPOtdyjQe+F/miKmUBC meA5jmi6Rkjcw== Original-Received: from alfajor (unknown [216.154.50.221]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id EF39812040F; Mon, 9 Mar 2020 18:05:13 -0400 (EDT) In-Reply-To: <20200309202259.GA16294@ACM> (Alan Mackenzie's message of "Mon, 9 Mar 2020 20:22:59 +0000") 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:245418 Archived-At: > Why is (defvar foo) a no-op? Because that's what it has been since its introduction many many years ago (Emacs-21? 20? 19? 18?). In Emacs-24, a decision had to made about how to deal with it. Given the many packages that did (and many still do) things like (defvar date) making such defvars have global impacts means that any code using `date` as a lexical variable would break whenever that other package with the `(defvar date)` happened to be loaded. This is still true if that other package does (defvar date nil) but such definition of variables with no namespace prefix has been widely understood as a bug since "for ever", so they're vanishingly rare (contrary to the (defvar ) where doesn't have a namespace prefix, which I also consider as bugs but are still very widespread). So the Emacs-24 design of lexical-binding make (defvar ) be a declaration which only affects "the current scope". I don't claim it is a perfect design, but it's what we have (introduced in Emacs-24) and in retrospect it has worked fairly well, striking a pretty good balance between the desire to minimize the amount of changes needed when converting a file from dynamic to lexical scoping, the need to work alongside the many pre-existing files which won't be changed, the need to provide reasonably sane semantics which aren't too badly affected by "unrelated" packages, ... > Why does it not set the declared_special bit inside the symbol? As explained, this would make lots of existing packages break other unrelated packages. In any case, this boat has sailed many years ago. >> It's rather unusual. > Even if that's the case, it doesn't make it unimportant. Let binding > from the minibuffer should work consistently, its effect not varying > chaotically between dynamic and lexical binding. let-binding is the thing that is different between dynamic and lexical binding, so it is affected, by definition. As for "chaotically", it's a matter of judgment. You're clearly not familiar with the behavior of lexical-binding, so it's no surprise you find it chaotic. > See above. defvar should not be a no-op. It was designed as a no-op from the very beginning, long before `lexical-binding` was introduced. `lexical-binding` is what made it less of a no-op, so it seems you're arguing on favor of `lexical-binding` unwittingly. > It shouldn't be necessary to write (defvar foo) in more than one file. Then write (defvar foo nil). > Why did you not initiate a discussion on emacs-devel before committing > this patch? It was discussed somewhere for a while. Lesseee.... Oh, I found it: https://debbugs.gnu.org/30078 -- Stefan