From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Noam Postavsky Newsgroups: gmane.emacs.bugs Subject: bug#18059: 24.3.92; defvar and special variables Date: Sun, 18 Feb 2018 17:28:26 -0500 Message-ID: <87fu5y53w5.fsf@gmail.com> References: <87ha2c7lxy.fsf@web.de> <87mv0gbq33.fsf@users.sourceforge.net> <87y3k0bdm9.fsf@web.de> <87inb4bbse.fsf@users.sourceforge.net> <873727bkud.fsf@users.sourceforge.net> <87efloa000.fsf@users.sourceforge.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: blaine.gmane.org 1518992842 19349 195.159.176.226 (18 Feb 2018 22:27:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 18 Feb 2018 22:27:22 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) Cc: Michael Heerdegen , 18059@debbugs.gnu.org, Stefan Monnier To: Noam Postavsky Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Feb 18 23:27:17 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1enXQO-0004Ry-L9 for geb-bug-gnu-emacs@m.gmane.org; Sun, 18 Feb 2018 23:27:12 +0100 Original-Received: from localhost ([::1]:46767 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1enXSL-0000cE-2W for geb-bug-gnu-emacs@m.gmane.org; Sun, 18 Feb 2018 17:29:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33166) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1enXSD-0000bq-KZ for bug-gnu-emacs@gnu.org; Sun, 18 Feb 2018 17:29:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1enXSA-00076C-CQ for bug-gnu-emacs@gnu.org; Sun, 18 Feb 2018 17:29:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:42374) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1enXSA-000762-4U for bug-gnu-emacs@gnu.org; Sun, 18 Feb 2018 17:29:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1enXS9-0006cp-Rm for bug-gnu-emacs@gnu.org; Sun, 18 Feb 2018 17:29:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Noam Postavsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 18 Feb 2018 22:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18059 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 18059-submit@debbugs.gnu.org id=B18059.151899291725433 (code B ref 18059); Sun, 18 Feb 2018 22:29:01 +0000 Original-Received: (at 18059) by debbugs.gnu.org; 18 Feb 2018 22:28:37 +0000 Original-Received: from localhost ([127.0.0.1]:50271 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1enXRl-0006c8-0K for submit@debbugs.gnu.org; Sun, 18 Feb 2018 17:28:37 -0500 Original-Received: from mail-io0-f169.google.com ([209.85.223.169]:41617) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1enXRj-0006bt-9c for 18059@debbugs.gnu.org; Sun, 18 Feb 2018 17:28:35 -0500 Original-Received: by mail-io0-f169.google.com with SMTP id e4so9427674iob.8 for <18059@debbugs.gnu.org>; Sun, 18 Feb 2018 14:28:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=pU1u0/xTSqKb3T/pOvJX+1+B5DvKppw1WRC7QvSQXAs=; b=d5FolYp0CIrTm03EFdu++tOfC4aC+zjPOsunmZ/CCyQK4/uZ5+gOu6/BPCoI9bbdrG MxFFHyyo+l1HgQfBAP6TLfqv/lbVI5HGzAytwDz4W1OySkkZ3hhfRPlFHtCPFXKb0Frt c2Hf3Or1jFpKcAq268lVh0XklVEN1xK7PHdxUL5gXBHG3A59dR9juedHnMyyt0giXwg9 ZiBZ/q/CnmucWrRy3ogYBbRWUEMIPU7PSJNAwN+oL9rvo6KZWs3f4AZFIDRv7BOU79U+ Y+QQv6y0s+baJ4b3g7IshdiE/26UaTlq1RASPAiyplY4b5fKC2ftG/3t/uyBlijF5D9H jH1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=pU1u0/xTSqKb3T/pOvJX+1+B5DvKppw1WRC7QvSQXAs=; b=WBM89Ewx6D4srT5rgsxua+HQ3ZnFYj+ecLlARESSyNa4vs6shGk8zsl1edq9yFlp37 Xj86Z44/p443AD6SvgMkgyz0ULzf5sw1SgrYEt4U1ZZ048nFE4ldCMBAPasSIki6Y/Y0 sZGalm6zVX4vhcWwDyi156lPopA/la7lQrhErdGr9wS3QFR87W9OPvCZSYnblcnqoHh2 cBo/2WMzpCsFoUJ/jmZ12wfE2j0LHdYxEk+HtSSq00aieomcZ9fxyEWhezO7L2fdxpiJ nOsQorzFT4Ipb2VjN8+cB92CWNLMeHQa/sS5sZz4SksWBFUJKG84Iebldg4YqN0HnCiY SDDQ== X-Gm-Message-State: APf1xPA3HHhU35mGKOccg70k7+PWjEY3tj6cTwx5jA/oOZ9gYMUDQLkf tjFrluC2u/cfZku0PjZVNoRnLQ== X-Google-Smtp-Source: AH8x227et3AUPCPRnzjMBINBaGXr01mC6xw9N9jtM5wpINYd3hZJ4UX7kWcHgBoDRm9diaK4FE5EvA== X-Received: by 10.107.34.199 with SMTP id i190mr6623352ioi.185.1518992909496; Sun, 18 Feb 2018 14:28:29 -0800 (PST) Original-Received: from zebian (cbl-45-2-119-34.yyz.frontiernetworks.ca. [45.2.119.34]) by smtp.googlemail.com with ESMTPSA id z3sm18367612itf.0.2018.02.18.14.28.27 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 18 Feb 2018 14:28:28 -0800 (PST) In-Reply-To: <87efloa000.fsf@users.sourceforge.net> (Noam Postavsky's message of "Tue, 13 Feb 2018 19:27:43 -0500") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:143444 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Noam Postavsky writes: > Noam Postavsky writes: > >> Stefan Monnier writes: >> >>>> I noticed doing (let () (defvar x)) seems to be the same as (progn >>>> (defvar x)), which may be a bug. >>> >>> Both interpretations would make sense, so given the lack of >>> documentation about the intention, we could consider it as a feature as >>> much as a bug. >>> >>> Have you checked whether the behavior is the same with the >>> byte-compiler? >> >> Yes, it's the same. > > It's the same when let-binding a lexical variable, but not when binding > a dynamic one. > > ;; -*- lexical-binding: t -*- > > (defvar foo-dynamic 'foo) > > (let ((foo-dynamic 99)) > (defvar x)) > > (let ((x 1)) > (setq testfun (lambda () x))) > > (message "%S" (funcall testfun)) > > gives > > Symbol=E2=80=99s value as variable is void: x > > when running the interpreted version, and > > 1 > > when running the compiled version. This let-block thing feels more like a bug to me, so I'm inclined to leave it out of the manual. I'm also not so sure about putting in examples into the manual; the shortest and simplest I could come up with is this, but I don't know that it's worth putting in. This example demonstrates the effects of using @code{defvar} without an initial value: @example @group (let ((x 'lexical)) (defun get-lexical-x () x)) (defvar x) (defun get-dynamic-x () x) (let ((x 'dynamic)) (list (get-dynamic-x) (get-lexical-x))) @result{} (dynamic lexical) @end group @end example Here's the patch I have in my local repo right now: --=-=-= Content-Type: text/plain Content-Disposition: attachment; filename=v2-0001-Explain-more-about-defvar-foo-form-Bug-18059.patch Content-Description: patch >From 20757fcabb82828e63096bcd02faee2ec54e3afb Mon Sep 17 00:00:00 2001 From: Noam Postavsky Date: Sat, 10 Feb 2018 14:06:05 -0500 Subject: [PATCH v2] Explain more about (defvar foo) form (Bug#18059) * doc/lispref/variables.texi (Defining Variables): * doc/lispref/compile.texi (Compiler Errors): Emphasize that omitting VALUE for `defvar' marks the variable special only locally. --- doc/lispref/compile.texi | 4 ++-- doc/lispref/variables.texi | 11 ++++++++--- 2 files changed, 10 insertions(+), 5 deletions(-) diff --git a/doc/lispref/compile.texi b/doc/lispref/compile.texi index 0e39866d34..77d35be1ba 100644 --- a/doc/lispref/compile.texi +++ b/doc/lispref/compile.texi @@ -500,8 +500,8 @@ Compiler Errors @item Likewise, you can tell the compiler that a variable is defined using @code{defvar} with no initial value. (Note that this marks the -variable as special, i.e.@: dynamically bound.) @xref{Defining -Variables}. +variable as special, i.e.@: dynamically bound, but only within the +file.) @xref{Defining Variables}. @end itemize You can also suppress any and all compiler warnings within a certain diff --git a/doc/lispref/variables.texi b/doc/lispref/variables.texi index e025d3fd10..a6df16d03f 100644 --- a/doc/lispref/variables.texi +++ b/doc/lispref/variables.texi @@ -442,9 +442,13 @@ Defining Variables evaluated and @var{symbol} is set to the result. But if @var{symbol} is not void, @var{value} is not evaluated, and @var{symbol}'s value is left unchanged. If @var{value} is omitted, the value of @var{symbol} -is not changed in any case. Using @code{defvar} with no value is one -method of suppressing byte compilation warnings, see @ref{Compiler -Errors}. +is not changed in any case. + +Note that specifying a value, even @code{nil}, marks the variable as +special permanently. Whereas if @var{value} is omitted then the +variable is only marked special locally (i.e.@: for the rest of the +current file). This can be useful for suppressing byte compilation +warnings, see @ref{Compiler Errors}. If @var{symbol} has a buffer-local binding in the current buffer, @code{defvar} acts on the default value, which is buffer-independent, @@ -488,6 +492,7 @@ Defining Variables The @code{defvar} form returns @var{symbol}, but it is normally used at top level in a file where its value does not matter. + @end defspec @cindex constant variables -- 2.11.0 --=-=-=--