From unknown Sun Jun 22 19:06:34 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#55156 <55156@debbugs.gnu.org> To: bug#55156 <55156@debbugs.gnu.org> Subject: Status: [PATCH] eval.c: New functions `defvar-f` and `defconst-f` Reply-To: bug#55156 <55156@debbugs.gnu.org> Date: Mon, 23 Jun 2025 02:06:34 +0000 retitle 55156 [PATCH] eval.c: New functions `defvar-f` and `defconst-f` reassign 55156 emacs submitter 55156 Stefan Monnier severity 55156 normal tag 55156 patch thanks From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 27 17:46:46 2022 Received: (at submit) by debbugs.gnu.org; 27 Apr 2022 21:46:47 +0000 Received: from localhost ([127.0.0.1]:44653 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njpUk-0006A5-83 for submit@debbugs.gnu.org; Wed, 27 Apr 2022 17:46:46 -0400 Received: from lists.gnu.org ([209.51.188.17]:41652) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njpUi-00069x-NP for submit@debbugs.gnu.org; Wed, 27 Apr 2022 17:46:45 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58998) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1njpUi-0006bY-BW for bug-gnu-emacs@gnu.org; Wed, 27 Apr 2022 17:46:44 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:50435) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1njpUe-0005Tf-Pt for bug-gnu-emacs@gnu.org; Wed, 27 Apr 2022 17:46:42 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id C4B9D10028F for ; Wed, 27 Apr 2022 17:46:38 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 5E258100171 for ; Wed, 27 Apr 2022 17:46:36 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1651095996; bh=mEOf1BP5yIGJfXyomuwYgt1/UxwEWE+2ZUZpvzgkaDM=; h=From:To:Subject:Date:From; b=QB4viH5mIwHX7PG5hmr/1MPddZtVZSBJoNPHcseCi5eVCa4TNcFPHIH923S84ahxk 4Al8o1SnVq12M2qEvuYHUcQM3e4OEyuwSIHIlIDbuzuhqb2opnJVbHIHIq9J/nKhRw Ds5u6wjR7jUXE6taRf03O1QnmCmCBQW1ASQ3a8l/DeCitoQQrhNXhqPxaXpoB10DkC n4Wa0UQBbnECgAH3tCQ6SWRqgKM89dsHK4p56L/7ncKg4EALChKCt14Sp1H+9356Az /IW1AtMa65bcr5+ZynhoS57k+Ek6XAgQKH00AKvVKqYL8+n2xf1e0NOcYTeq3G8OSU 4udDelglCsXjw== Received: from alfajor (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3CF88120680 for ; Wed, 27 Apr 2022 17:46:36 -0400 (EDT) From: Stefan Monnier To: bug-gnu-emacs@gnu.org Subject: [PATCH] eval.c: New functions `defvar-f` and `defconst-f` Date: Wed, 27 Apr 2022 17:46:22 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.132 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain PROLO_LEO2 0.1 Meta Catches all Leo drug variations so far X-SPAM-LEVEL: Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --=-=-= Content-Type: text/plain Tags: patch Tags: patch --=-=-= Content-Type: text/patch Content-Disposition: inline; filename=0001-eval.c-New-functions-defvar-f-and-defconst-f.patch >From b0e07492cfe82ab3c49e663e72188ba5e90b7f76 Mon Sep 17 00:00:00 2001 From: Stefan Monnier Date: Wed, 27 Apr 2022 17:44:20 -0400 Subject: [PATCH] eval.c: New functions `defvar-f` and `defconst-f` The bytecode interpreter can't directly call special forms, so the byte-compiler usually converts special forms into some sequence of byte codes (basically, providing a duplicate definition of the special form). There are still two exceptions to this: `defconst` and `defvar`, where the compiler instead generates a convoluted chunk of code like: (funcall '(lambda (x) (defvar x )) ) where the quote makes sure we keep the function non-compiled, so as to end up running the special form at run time. The patch below gets rid of this workaround by introducing `defvar-f` and `defconst-f` which provide a *functional* interface to the functionality of the corresponding special form. This changes the behavior of (defvar ) because (defvar-f ' ) will now always evaluate whereas previously the doc promised that would only be evaluated if was not yet bound. This sounds scary, but the reality is less so: while the behavior of the special form obeyed its doc in this respect, the behavior of the convoluted code generated by the byte-compiler did not(!) and always evaluated the part anyway. So this patch also aligns the two semantics to provide the same behavior. * src/eval.c (Fdefvar_f, Fdefconst_f): New functions, extracted from `Fdef(var|const)`. (Fdefvar, Fdefconst): Use them. (syms_of_eval): `defsubr` the new functions. * lisp/emacs-lisp/bytecomp.el (byte-compile-tmp-var): Delete const. (byte-compile-defvar): Simplify using the new `def(car|const)-f` functions. * doc/lispref/variables.texi (Defining Variables): Adjust the doc of `defvar` to reflect the actual semantics implemented. Don't state explicitly if the `value` is always evaluated or not. --- doc/lispref/variables.texi | 14 ++++---- lisp/emacs-lisp/bytecomp.el | 20 ++++------- src/eval.c | 72 +++++++++++++++++++++++-------------- 3 files changed, 58 insertions(+), 48 deletions(-) diff --git a/doc/lispref/variables.texi b/doc/lispref/variables.texi index f0e3f337a69..264fcbcfe8e 100644 --- a/doc/lispref/variables.texi +++ b/doc/lispref/variables.texi @@ -510,10 +510,10 @@ Defining Variables (@pxref{Variable Scoping}). If @var{value} is specified, and @var{symbol} is void (i.e., it has no -dynamically bound value; @pxref{Void Variables}), then @var{value} is -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} +dynamically bound value; @pxref{Void Variables}), then @var{symbol} is +set to the result of evaluating of @var{value}. But if @var{symbol} +is not void @var{symbol}'s value is left unchanged. +If @var{value} is omitted, the value of @var{symbol} is not changed in any case. Note that specifying a value, even @code{nil}, marks the variable as @@ -527,9 +527,9 @@ Defining Variables rather than the buffer-local binding. It sets the default value if the default value is void. @xref{Buffer-Local Variables}. -If @var{symbol} is already lexically bound (e.g., if the @code{defvar} -form occurs in a @code{let} form with lexical binding enabled), then -@code{defvar} sets the dynamic value. The lexical binding remains in +If @var{symbol} is already let bound (e.g., if the @code{defvar} +form occurs in a @code{let} form), then @code{defvar} sets the dynamic +outer value. The let binding remains in effect until its binding construct exits. @xref{Variable Scoping}. @cindex @code{eval-defun}, and @code{defvar} forms diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el index c0dffe544cf..68a664c7129 100644 --- a/lisp/emacs-lisp/bytecomp.el +++ b/lisp/emacs-lisp/bytecomp.el @@ -4887,8 +4887,6 @@ byte-compile-make-obsolete-variable (push (nth 1 (nth 1 form)) byte-compile-global-not-obsolete-vars)) (byte-compile-normal-call form)) -(defconst byte-compile-tmp-var (make-symbol "def-tmp-var")) - (defun byte-compile-defvar (form) ;; This is not used for file-level defvar/consts. (when (and (symbolp (nth 1 form)) @@ -4901,7 +4899,6 @@ byte-compile-defvar (byte-compile-docstring-length-warn form) (let ((fun (nth 0 form)) (var (nth 1 form)) - (value (nth 2 form)) (string (nth 3 form))) (when (or (> (length form) 4) (and (eq fun 'defconst) (null (cddr form)))) @@ -4922,17 +4919,12 @@ byte-compile-defvar "third arg to `%s %s' is not a string: %s" fun var string)) (byte-compile-form-do-effect - (if (cddr form) ; `value' provided - ;; Quote with `quote' to prevent byte-compiling the body, - ;; which would lead to an inf-loop. - `(funcall '(lambda (,byte-compile-tmp-var) - (,fun ,var ,byte-compile-tmp-var ,@(nthcdr 3 form))) - ,value) - (if (eq fun 'defconst) - ;; This will signal an appropriate error at runtime. - `(eval ',form) - ;; A simple (defvar foo) just returns foo. - `',var))))) + (if (or (cddr form) ; `value' provided + (eq fun 'defconst)) + ;; Delegate the actual work to the `-f' version of the special form. + `(,(intern (format "%s-f" fun)) ',var ,@(nthcdr 2 form)) + ;; A simple (defvar foo) just returns foo. + `',var)))) (defun byte-compile-autoload (form) (and (macroexp-const-p (nth 1 form)) diff --git a/src/eval.c b/src/eval.c index 77ec47e2b79..10212708c23 100644 --- a/src/eval.c +++ b/src/eval.c @@ -763,17 +763,14 @@ DEFUN ("defvar", Fdefvar, Sdefvar, 1, UNEVALLED, 0, so that it is always dynamically bound even if `lexical-binding' is t. If SYMBOL's value is void and the optional argument INITVALUE is -provided, INITVALUE is evaluated and the result used to set SYMBOL's -value. If SYMBOL is buffer-local, its default value is what is set; +provided, INITVALUE is used to set SYMBOL's value. +If SYMBOL is buffer-local, its default value is what is set; buffer-local values are not affected. If INITVALUE is missing, SYMBOL's value is not set. -If SYMBOL has a local binding, then this form affects the local -binding. This is usually not what you want. Thus, if you need to -load a file defining variables, with this form or with `defconst' or -`defcustom', you should always load that file _outside_ any bindings -for these variables. (`defconst' and `defcustom' behave similarly in -this respect.) +If SYMBOL is let-bound, then this form does not affect the local let +binding but the outer (toplevel) binding. +(`defcustom' behaves similarly in this respect.) The optional argument DOCSTRING is a documentation string for the variable. @@ -784,7 +781,7 @@ DEFUN ("defvar", Fdefvar, Sdefvar, 1, UNEVALLED, 0, usage: (defvar SYMBOL &optional INITVALUE DOCSTRING) */) (Lisp_Object args) { - Lisp_Object sym, tem, tail; + Lisp_Object sym, tail; sym = XCAR (args); tail = XCDR (args); @@ -796,24 +793,8 @@ DEFUN ("defvar", Fdefvar, Sdefvar, 1, UNEVALLED, 0, if (!NILP (XCDR (tail)) && !NILP (XCDR (XCDR (tail)))) error ("Too many arguments"); Lisp_Object exp = XCAR (tail); - - tem = Fdefault_boundp (sym); tail = XCDR (tail); - - /* Do it before evaluating the initial value, for self-references. */ - Finternal__define_uninitialized_variable (sym, CAR (tail)); - - if (NILP (tem)) - Fset_default (sym, eval_sub (exp)); - else - { /* Check if there is really a global binding rather than just a let - binding that shadows the global unboundness of the var. */ - union specbinding *binding = default_toplevel_binding (sym); - if (binding && EQ (specpdl_old_value (binding), Qunbound)) - { - set_specpdl_old_value (binding, eval_sub (exp)); - } - } + return Fdefvar_f (sym, eval_sub (exp), CAR (tail)); } else if (!NILP (Vinternal_interpreter_environment) && (SYMBOLP (sym) && !XSYMBOL (sym)->u.s.declared_special)) @@ -832,6 +813,33 @@ DEFUN ("defvar", Fdefvar, Sdefvar, 1, UNEVALLED, 0, return sym; } +DEFUN ("defvar-f", Fdefvar_f, Sdefvar_f, 2, 3, 0, + doc: /* Like `defvar' but as a function. */) + (Lisp_Object sym, Lisp_Object initvalue, Lisp_Object docstring) +{ + Lisp_Object tem; + + CHECK_SYMBOL (sym); + + tem = Fdefault_boundp (sym); + + /* Do it before evaluating the initial value, for self-references. */ + Finternal__define_uninitialized_variable (sym, docstring); + + if (NILP (tem)) + Fset_default (sym, initvalue); + else + { /* Check if there is really a global binding rather than just a let + binding that shadows the global unboundness of the var. */ + union specbinding *binding = default_toplevel_binding (sym); + if (binding && EQ (specpdl_old_value (binding), Qunbound)) + { + set_specpdl_old_value (binding, initvalue); + } + } + return sym; +} + DEFUN ("defconst", Fdefconst, Sdefconst, 2, UNEVALLED, 0, doc: /* Define SYMBOL as a constant variable. This declares that neither programs nor users should ever change the @@ -861,9 +869,17 @@ DEFUN ("defconst", Fdefconst, Sdefconst, 2, UNEVALLED, 0, error ("Too many arguments"); docstring = XCAR (XCDR (XCDR (args))); } + tem = eval_sub (XCAR (XCDR (args))); + return Fdefconst_f (sym, tem, docstring); +} +DEFUN ("defconst-f", Fdefconst_f, Sdefconst_f, 2, 3, 0, + doc: /* Like `defconst' but as a function. */) + (Lisp_Object sym, Lisp_Object initvalue, Lisp_Object docstring) +{ + CHECK_SYMBOL (sym); + Lisp_Object tem = initvalue; Finternal__define_uninitialized_variable (sym, docstring); - tem = eval_sub (XCAR (XCDR (args))); if (!NILP (Vpurify_flag)) tem = Fpurecopy (tem); Fset_default (sym, tem); /* FIXME: set-default-toplevel-value? */ @@ -4325,9 +4341,11 @@ syms_of_eval (void) defsubr (&Sdefault_toplevel_value); defsubr (&Sset_default_toplevel_value); defsubr (&Sdefvar); + defsubr (&Sdefvar_f); defsubr (&Sdefvaralias); DEFSYM (Qdefvaralias, "defvaralias"); defsubr (&Sdefconst); + defsubr (&Sdefconst_f); defsubr (&Sinternal__define_uninitialized_variable); defsubr (&Smake_var_non_special); defsubr (&Slet); -- 2.35.1 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 27 18:11:18 2022 Received: (at 55156) by debbugs.gnu.org; 27 Apr 2022 22:11:18 +0000 Received: from localhost ([127.0.0.1]:44699 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njpsT-0006s2-PL for submit@debbugs.gnu.org; Wed, 27 Apr 2022 18:11:18 -0400 Received: from quimby.gnus.org ([95.216.78.240]:47488) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njpsS-0006rl-DD for 55156@debbugs.gnu.org; Wed, 27 Apr 2022 18:11:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=TTPO6LlwMMsIUiQIsd0H95uejg8LyoYyo0i9jqzAAec=; b=C1cmgmh05CCMdUYx5NkCiqx/Ns /j7kvfefuMcXS9cqnE1lkCAdm+7JMcDmUlpMrPBaL7YM/VyrDiI5RhkuNxlmnqxN/ihE9PQZXbAEe 7S6tKNmrIDoWcQZfDJUMHKpvNnuf3xpm3dGIeh983VJXCKsy/qPVEX28FEaFeFWovwl0=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1njpsI-0001dS-52; Thu, 28 Apr 2022 00:11:08 +0200 From: Lars Ingebrigtsen To: 55156@debbugs.gnu.org Subject: Re: bug#55156: [PATCH] eval.c: New functions `defvar-f` and `defconst-f` References: Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAElBMVEX5+OrQyJ+Zj15f Wj4YFQ3///9CLrHKAAAAAWJLR0QF+G/pxwAAAAd0SU1FB+YEGxYKCwvHyqEAAAF4SURBVDjLlZRR euwgCIUx7QKE2UCFLqAjbqA1+19TD/k6DXPjfWiSh8RfDnjEEB1Xsf35eqO/go//gc8fsPk/YMfk GmBfgE6FtnEFJG8b8Y/U9HEC0sLyAJZBUX18z5GkiKw/inqWoq3bL8gRRdSXUkVsuvsiR2HvZt7V ASbuXyCGiNG1Q9J9YooegFUdA009cs25u9oRcEeCoZj2nixhraUN32d378lj6rdGEJrTm5ieXpJz I3GMzy99Hzmi34sNlAkpT/tI1VyxvBFLfJIiqSWK98itJ6Fa6mY7ysG42UzlFq63MGpGSK6qNYAx DilLQLnWF+SNB86c++GV+DU88vA3lev3Ul+mjhCC7ym5NJYZI+iQueccUtjGiKo8u+uMhaji1T03 MNoZMSNAXkUA7lWOuc/ti2aXtvnlFIRXKMyvBEfg6MQrEGY0b7L1TM6rk4YcVOFW2rqzRREhsgII IrEViGa8LUEp7GsgugToB1v9GYhZL7n3b3eu4UEOh9agAAAAJXRFWHRkYXRlOmNyZWF0ZQAyMDIy LTA0LTI3VDIyOjEwOjExKzAwOjAwyABvLgAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMi0wNC0yN1Qy MjoxMDoxMSswMDowMLld15IAAAAASUVORK5CYII= X-Now-Playing: Mark Pistel's _This Is Fascism (2)_: "This Is Fascism (Consolidated Mix)" Date: Thu, 28 Apr 2022 00:11:05 +0200 In-Reply-To: (Stefan Monnier via's message of "Wed, 27 Apr 2022 17:46:22 -0400") Message-ID: <87tuaep47a.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: > This sounds scary, but the reality is less so: while the behavior of > the special form obeyed its doc in this respect, the behavior of the > convoluted code generated by the byte-compiler did not(! [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55156 Cc: Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: > This sounds scary, but the reality is less so: while the behavior of > the special form obeyed its doc in this respect, the behavior of the > convoluted code generated by the byte-compiler did not(!) and always > evaluated the part anyway. So this patch also aligns the two > semantics to provide the same behavior. Uhm -- are you saying that if you load an .elc file twice, the parts in the defvars will be evaluated twice? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 27 18:29:49 2022 Received: (at 55156) by debbugs.gnu.org; 27 Apr 2022 22:29:49 +0000 Received: from localhost ([127.0.0.1]:44723 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njqAO-0007NB-Op for submit@debbugs.gnu.org; Wed, 27 Apr 2022 18:29:48 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:52175) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njqAM-0007My-Bs for 55156@debbugs.gnu.org; Wed, 27 Apr 2022 18:29:47 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 856C410019F; Wed, 27 Apr 2022 18:29:40 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 34E841000C4; Wed, 27 Apr 2022 18:29:39 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1651098579; bh=647+BJ5rIL+51VdEhjYyRPO+il3YSiTLrNsX3u8YpZc=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=VNI5Akutm8fC4cykMtBRA6/WpMTCZD7Voxzs4swi2zlyDRE3rMpMIH+8C1vnyqhDX CdZQIj2eulmjTzz1ZfP6cTlJhX7d98b+JDsJsZguC1HEWa7gBEUuJenwebpVTKySqd puMC+7OlEf/4zy0wBI9jlPlcBJ+db6NDY16Oph3r2aepgHzPTzrmJDy5vlZL52K23U VuW0Rgixf63Ed5Yvg8mhu6RfC79OWSqYdPBfQit1MuzEoylB+uqerDL6Qr7hd9FUBU JafIRJZAwSU2BLv1D64DufbS3exiTWAYd85RUdoPyCYJ4RBu+j+vddcc7hTKuIGod/ NlInJmodUc30g== Received: from alfajor (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 1C850120298; Wed, 27 Apr 2022 18:29:39 -0400 (EDT) From: Stefan Monnier To: Lars Ingebrigtsen Subject: Re: bug#55156: [PATCH] eval.c: New functions `defvar-f` and `defconst-f` Message-ID: References: <87tuaep47a.fsf@gnus.org> Date: Wed, 27 Apr 2022 18:29:38 -0400 In-Reply-To: <87tuaep47a.fsf@gnus.org> (Lars Ingebrigtsen's message of "Thu, 28 Apr 2022 00:11:05 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.182 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55156 Cc: 55156@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Lars Ingebrigtsen [2022-04-28 00:11:05] wrote: > Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of > text editors" writes: > >> This sounds scary, but the reality is less so: while the behavior of >> the special form obeyed its doc in this respect, the behavior of the >> convoluted code generated by the byte-compiler did not(!) and always >> evaluated the part anyway. So this patch also aligns the two >> semantics to provide the same behavior. > > Uhm -- are you saying that if you load an .elc file twice, the > parts in the defvars will be evaluated twice? Try: (let ((f (byte-compile '(lambda (x) (defvar sm-x (progn (message "hello %S" x) x)))))) (funcall f 5) (funcall f 6)) and check *Messages* :-( If we prefer keeping the behavior we currently promise, we can of course do that (just change `defvar-f` so it takes a function of no argument as second arg, it makes the generated code (and the C code) a bit less simple, but it's no worse than what we currently have). Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 27 18:34:03 2022 Received: (at 55156) by debbugs.gnu.org; 27 Apr 2022 22:34:03 +0000 Received: from localhost ([127.0.0.1]:44730 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njqEV-0007Vs-AA for submit@debbugs.gnu.org; Wed, 27 Apr 2022 18:34:03 -0400 Received: from quimby.gnus.org ([95.216.78.240]:47566) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njqET-0007VM-4x for 55156@debbugs.gnu.org; Wed, 27 Apr 2022 18:34:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=ZWZHdsiHbCgLquNMOA/rTB3p3+6wUb789TOEGddG+oc=; b=lvrAd3wiYPlKPglT62i/wCCDgX niO3CVk5WqJWFU4Jf1RkGT0jNFBrgcXPl1c5Vas9fxI0HSXWDae0gmub9PLrYCfWDnCZi2ZUcVkWq eypLDf1ky2MUizTpxEgoXY/NAjXCAdMnogve3gqHOBrIgDUp0Y1Wl6n7ZvxOg3jZZiCM=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1njqEI-0001mq-VX; Thu, 28 Apr 2022 00:33:53 +0200 From: Lars Ingebrigtsen To: Stefan Monnier Subject: Re: bug#55156: [PATCH] eval.c: New functions `defvar-f` and `defconst-f` References: <87tuaep47a.fsf@gnus.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAElBMVEX5+OrQyJ+Zj15f Wj4YFQ3///9CLrHKAAAAAWJLR0QF+G/pxwAAAAd0SU1FB+YEGxYKCwvHyqEAAAF4SURBVDjLlZRR euwgCIUx7QKE2UCFLqAjbqA1+19TD/k6DXPjfWiSh8RfDnjEEB1Xsf35eqO/go//gc8fsPk/YMfk GmBfgE6FtnEFJG8b8Y/U9HEC0sLyAJZBUX18z5GkiKw/inqWoq3bL8gRRdSXUkVsuvsiR2HvZt7V ASbuXyCGiNG1Q9J9YooegFUdA009cs25u9oRcEeCoZj2nixhraUN32d378lj6rdGEJrTm5ieXpJz I3GMzy99Hzmi34sNlAkpT/tI1VyxvBFLfJIiqSWK98itJ6Fa6mY7ysG42UzlFq63MGpGSK6qNYAx DilLQLnWF+SNB86c++GV+DU88vA3lev3Ul+mjhCC7ym5NJYZI+iQueccUtjGiKo8u+uMhaji1T03 MNoZMSNAXkUA7lWOuc/ti2aXtvnlFIRXKMyvBEfg6MQrEGY0b7L1TM6rk4YcVOFW2rqzRREhsgII IrEViGa8LUEp7GsgugToB1v9GYhZL7n3b3eu4UEOh9agAAAAJXRFWHRkYXRlOmNyZWF0ZQAyMDIy LTA0LTI3VDIyOjEwOjExKzAwOjAwyABvLgAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMi0wNC0yN1Qy MjoxMDoxMSswMDowMLld15IAAAAASUVORK5CYII= X-Now-Playing: Carl Cox's _This Is Fascism (2)_: "This Is Fascism (Burning Gold Mix)" Date: Thu, 28 Apr 2022 00:33:47 +0200 In-Reply-To: (Stefan Monnier's message of "Wed, 27 Apr 2022 18:29:38 -0400") Message-ID: <87pml2p35g.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Stefan Monnier writes: >> Uhm -- are you saying that if you load an .elc file twice, the >> parts in the defvars will be evaluated twice? > > Try: > > (let ((f (byte-compile > '(lambda (x) > (defvar sm-x (progn (messa [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55156 Cc: 55156@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Stefan Monnier writes: >> Uhm -- are you saying that if you load an .elc file twice, the >> parts in the defvars will be evaluated twice? > > Try: > > (let ((f (byte-compile > '(lambda (x) > (defvar sm-x (progn (message "hello %S" x) x)))))) > (funcall f 5) > (funcall f 6)) > > and check *Messages* :-( Oh, if we call a function containing the defvar... Yes, that's probably rare enough that nobody's noticed. I tried to byte-compile a file and just load the .elc a few times, and the message was only done once: (defvar this-thing (message "hello")) > If we prefer keeping the behavior we currently promise, we can of course > do that (just change `defvar-f` so it takes a function of no argument as > second arg, it makes the generated code (and the C code) a bit less > simple, but it's no worse than what we currently have). I think I'd prefer keeping the behaviour we currently promise, but I don't have a strong opinion. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 27 21:30:02 2022 Received: (at 55156) by debbugs.gnu.org; 28 Apr 2022 01:30:02 +0000 Received: from localhost ([127.0.0.1]:44775 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njsyf-00063y-1u for submit@debbugs.gnu.org; Wed, 27 Apr 2022 21:30:02 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:30935) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njsyZ-00063j-PO for 55156@debbugs.gnu.org; Wed, 27 Apr 2022 21:29:51 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id ADB0010027D; Wed, 27 Apr 2022 21:29:41 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 7E6371000C4; Wed, 27 Apr 2022 21:29:39 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1651109379; bh=h+K0L0FSWJdWdRqs+HkIk55KhJR/sFH82Drn7GFeKug=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=mKIDkETO03bmkmmUbbS4OBEPlX4Nxj/SmQyBRzmB0Mm7mLNhcxymv5Iy4Za7xuOtC CH1XJF6F8L5sNI7pCuCEVQY0ZqKRDCGWI/M2UlskYxfpbjO0tIcgc6TUt2x6VzpwDt ltnbQzhTAYvc35uKfdJOgb60u/ckKuDMl96bqEtJm+TzAc4ivZOihEGBslTZDBXbtF 6V7OIojbvKWNf/4usKhgzQfHWjm5RjsVAzQN/hOVDtHHiguGSqzlTu5l3trzga9G5/ /GlKlkpPr835yevULyz+7FxgGRuqDZ0uEZIuOxMo+pF9e8nnxzWRTEfQgkv5r5IevW D4z6U/4+P9afw== Received: from pastel (unknown [45.72.221.51]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 441971205E3; Wed, 27 Apr 2022 21:29:39 -0400 (EDT) From: Stefan Monnier To: Lars Ingebrigtsen Subject: Re: bug#55156: [PATCH] eval.c: New functions `defvar-f` and `defconst-f` Message-ID: References: <87tuaep47a.fsf@gnus.org> <87pml2p35g.fsf@gnus.org> Date: Wed, 27 Apr 2022 21:29:34 -0400 In-Reply-To: <87pml2p35g.fsf@gnus.org> (Lars Ingebrigtsen's message of "Thu, 28 Apr 2022 00:33:47 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.048 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55156 Cc: 55156@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> Try: >> >> (let ((f (byte-compile >> '(lambda (x) >> (defvar sm-x (progn (message "hello %S" x) x)))))) >> (funcall f 5) >> (funcall f 6)) >> >> and check *Messages* :-( > > Oh, if we call a function containing the defvar... Yes, that's probably > rare enough that nobody's noticed. > > I tried to byte-compile a file and just load the .elc a few times, and > the message was only done once: > > (defvar this-thing (message "hello")) Duh, I forgot about the toplevel special case, indeed. OK, now it makes sense. >> If we prefer keeping the behavior we currently promise, we can of course >> do that (just change `defvar-f` so it takes a function of no argument as >> second arg, it makes the generated code (and the C code) a bit less >> simple, but it's no worse than what we currently have). > I think I'd prefer keeping the behaviour we currently promise, So do I. I'll see about updating the patch. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 28 01:34:32 2022 Received: (at 55156) by debbugs.gnu.org; 28 Apr 2022 05:34:32 +0000 Received: from localhost ([127.0.0.1]:44975 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njwnQ-000483-DW for submit@debbugs.gnu.org; Thu, 28 Apr 2022 01:34:32 -0400 Received: from eggs.gnu.org ([209.51.188.92]:41044) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njwnP-00047r-28 for 55156@debbugs.gnu.org; Thu, 28 Apr 2022 01:34:31 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44428) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1njwnJ-0001OI-1s; Thu, 28 Apr 2022 01:34:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=horYWMiKXIYErLIVkegQ4OToDOT65Y9okIV107HBfX0=; b=Cj1G8zoyLeKm oeF8IphAMdybDNil1pYWuzPVDkBlWlAUZ6W6d30eic7bgHD64QP/8hDKGkELHRzGZ7JhkNTVBp8wd 0KvBv/daPVv8cNjtQ7evpqMZsrwJE1Mm1cNfDYJMrBe45eStpvxefS/QJ9+2lAblFgyf9DyomKscf DZGfclDmr3L8bkb25o4CY4F/ULGttorvqRH3mKFiVewxKb9bw5NGdQYVPGb462cf+PkMurXKE0CD8 usLQt+fe446O+KZu7RMHT50Kb+CScGqaV9NOF/OmyAxD6pyTu9r1ygo/MRXI86mfHHF1Qsyxx2Gmx J3eFDVwdu731L74sMq+JEw==; Received: from [87.69.77.57] (port=4606 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1njwnI-0005UK-GG; Thu, 28 Apr 2022 01:34:24 -0400 Date: Thu, 28 Apr 2022 08:34:23 +0300 Message-Id: <83sfpxbwkg.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (bug-gnu-emacs@gnu.org) Subject: Re: bug#55156: [PATCH] eval.c: New functions `defvar-f` and `defconst-f` References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55156 Cc: 55156@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Wed, 27 Apr 2022 17:46:22 -0400 > From: Stefan Monnier via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > The bytecode interpreter can't directly call special forms, so > the byte-compiler usually converts special forms into some sequence of > byte codes (basically, providing a duplicate definition of the special > form). There are still two exceptions to this: `defconst` and `defvar`, > where the compiler instead generates a convoluted chunk of code like: > > (funcall '(lambda (x) (defvar x )) ) > > where the quote makes sure we keep the function non-compiled, so as > to end up running the special form at run time. > > The patch below gets rid of this workaround by introducing `defvar-f` > and `defconst-f` which provide a *functional* interface to the > functionality of the corresponding special form. I have (almost) no opinion on the code changes, but the documentation changes "need work", IMO: > If @var{value} is specified, and @var{symbol} is void (i.e., it has no > -dynamically bound value; @pxref{Void Variables}), then @var{value} is > -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} > +dynamically bound value; @pxref{Void Variables}), then @var{symbol} is > +set to the result of evaluating of @var{value}. But if @var{symbol} > +is not void @var{symbol}'s value is left unchanged. > +If @var{value} is omitted, the value of @var{symbol} > is not changed in any case. The new text lacks a comma after "not void", and "result of evaluating of VALUE" is IMO not good English. If all you wanted was to remove "is not evaluated", why not just do that and leave the rest as it was? > -If @var{symbol} is already lexically bound (e.g., if the @code{defvar} > -form occurs in a @code{let} form with lexical binding enabled), then > -@code{defvar} sets the dynamic value. The lexical binding remains in > +If @var{symbol} is already let bound (e.g., if the @code{defvar} > +form occurs in a @code{let} form), then @code{defvar} sets the dynamic > +outer value. The let binding remains in What is "dynamic outer value"? We don't have such terminology anywhere in the manual. > @@ -763,17 +763,14 @@ DEFUN ("defvar", Fdefvar, Sdefvar, 1, UNEVALLED, 0, > so that it is always dynamically bound even if `lexical-binding' is t. > > If SYMBOL's value is void and the optional argument INITVALUE is > -provided, INITVALUE is evaluated and the result used to set SYMBOL's > -value. If SYMBOL is buffer-local, its default value is what is set; > +provided, INITVALUE is used to set SYMBOL's value. > +If SYMBOL is buffer-local, its default value is what is set; > buffer-local values are not affected. If INITVALUE is missing, > SYMBOL's value is not set. This loses information, AFAIU: the previous doc string said INITVALUE was evaluated, the new one says nothing at all about evaluating it. If it is evaluated in some cases, please mention that; if it isn't evaluated at all, please say that. > -If SYMBOL has a local binding, then this form affects the local > -binding. This is usually not what you want. Thus, if you need to > -load a file defining variables, with this form or with `defconst' or > -`defcustom', you should always load that file _outside_ any bindings > -for these variables. (`defconst' and `defcustom' behave similarly in > -this respect.) > +If SYMBOL is let-bound, then this form does not affect the local let > +binding but the outer (toplevel) binding. > +(`defcustom' behaves similarly in this respect.) Isn't _this_ change (if it indeed constitutes a change in behavior) scary? > +DEFUN ("defvar-f", Fdefvar_f, Sdefvar_f, 2, 3, 0, > + doc: /* Like `defvar' but as a function. */) Please improve the doc string here. > +DEFUN ("defconst-f", Fdefconst_f, Sdefconst_f, 2, 3, 0, > + doc: /* Like `defconst' but as a function. */) Likewise. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 28 01:44:18 2022 Received: (at 55156) by debbugs.gnu.org; 28 Apr 2022 05:44:18 +0000 Received: from localhost ([127.0.0.1]:44981 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njwws-0004MB-Hv for submit@debbugs.gnu.org; Thu, 28 Apr 2022 01:44:18 -0400 Received: from eggs.gnu.org ([209.51.188.92]:42482) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njwwr-0004M0-CW for 55156@debbugs.gnu.org; Thu, 28 Apr 2022 01:44:17 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44514) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1njwwl-0002ea-Bs; Thu, 28 Apr 2022 01:44:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=SdD9MHbtrDzfYj8sojvGctpo8fnqhnzdKYRzeM3q5RI=; b=HGqCr6GzFICT YapcvbOvj/kAs1xdacFLuYqm6KRlSIWrjEAwvjTWwshIhJTxd9E9u17VEyr++DT9wX65LI1epmu+T iHUV0P5iljFN/AK1L/h2IyBkSfBbL344LoDeQaWtcOGE0jqhi1pwrGC6Fk4smZMVgE/Yxy6Ts5K02 Y3gsoebdU7UzQKZGOqMtI218mMXVTtXBZOvvGwaREU1JltxQNehG6nvWW6YghGpojWWI2FGKuMCS0 OFzKFGGnn0+WOjsAhb6LHROIOMqKGLxpBQBt8ANJf0Z2BS6f/J0B/jVUdOyMv6S42phqL+U/zPdpF 0JPFs6MkH7JlL4FFXhpJ8w==; Received: from [87.69.77.57] (port=1233 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1njwwk-00084W-4p; Thu, 28 Apr 2022 01:44:10 -0400 Date: Thu, 28 Apr 2022 08:44:08 +0300 Message-Id: <83r15hbw47.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87pml2p35g.fsf@gnus.org> (message from Lars Ingebrigtsen on Thu, 28 Apr 2022 00:33:47 +0200) Subject: Re: bug#55156: [PATCH] eval.c: New functions `defvar-f` and `defconst-f` References: <87tuaep47a.fsf@gnus.org> <87pml2p35g.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55156 Cc: 55156@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Date: Thu, 28 Apr 2022 00:33:47 +0200 > Cc: 55156@debbugs.gnu.org > > Oh, if we call a function containing the defvar... Yes, that's probably > rare enough that nobody's noticed. Famous last words. > I think I'd prefer keeping the behaviour we currently promise, but I > don't have a strong opinion. I sincerely question the wisdom of messing with this, for the reasons that were described, which seem to be some inelegant code somewhere in the bowels of the byte compiler. Do we really care enough about such inelegance to make potentially breaking changes in code that works for decades and causes zero trouble to Lisp programmers? And I'm quite sure that the replacement code might look no more elegant to people other than the author. I suggest that we all take a step back and re-evaluate the need for this. It is IME exactly the kind of change that prevents Emacs from becoming steadily more and more stable as time goes by. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 28 09:27:00 2022 Received: (at 55156) by debbugs.gnu.org; 28 Apr 2022 13:27:00 +0000 Received: from localhost ([127.0.0.1]:45781 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk4Ae-0004l6-6g for submit@debbugs.gnu.org; Thu, 28 Apr 2022 09:27:00 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:26716) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk4Ac-0004ku-OL for 55156@debbugs.gnu.org; Thu, 28 Apr 2022 09:26:59 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 5BE3E100164; Thu, 28 Apr 2022 09:26:53 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 8854F10028F; Thu, 28 Apr 2022 09:26:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1651152411; bh=7Erii6YWuzMbmmkCekV+1TQyN4dPNtxA2kl0ybVN+Rk=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=AbYvxazw4AKixqLS2dKBMx/Elmy71RczIi71CR0+quBBaMNnK6OBpVN3HAzhqTx9l 56G2CsZiU6vUGNd2vLpzCMb+nyKVCHsbnpj8YlcptevitQdudMcNKsjz0BR6V8vdri S6MMgrIDOvX/MnpmxfWN2KbsBolSdMLECuApc8kGR645/x8Bf977Jun0buaWuYPAo0 d0wlrYxMZm+HPCvuf2I70Sstdxj8pMoYrdpsiXW9AiWeA5Wk9qoVjA9IxQXTh3lNeL NNxavsYHtptWpV/nuQu+1WqvPvSd319AJmGgygPv5O5+5Ry+8xT28PkUST6oSG4itU 459oN2OnlK/8w== Received: from pastel (unknown [45.72.221.51]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 63CEF120483; Thu, 28 Apr 2022 09:26:51 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#55156: [PATCH] eval.c: New functions `defvar-f` and `defconst-f` Message-ID: References: <83sfpxbwkg.fsf@gnu.org> Date: Thu, 28 Apr 2022 09:26:50 -0400 In-Reply-To: <83sfpxbwkg.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 28 Apr 2022 08:34:23 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.048 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55156 Cc: 55156@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> -If @var{symbol} is already lexically bound (e.g., if the @code{defvar} >> -form occurs in a @code{let} form with lexical binding enabled), then >> -@code{defvar} sets the dynamic value. The lexical binding remains in >> +If @var{symbol} is already let bound (e.g., if the @code{defvar} >> +form occurs in a @code{let} form), then @code{defvar} sets the dynamic >> +outer value. The let binding remains in > > What is "dynamic outer value"? We don't have such terminology > anywhere in the manual. Good point, I should try and use the same terminology used by `default-toplevel-value` (and maybe refer to this function), thanks. >> @@ -763,17 +763,14 @@ DEFUN ("defvar", Fdefvar, Sdefvar, 1, UNEVALLED, 0, >> so that it is always dynamically bound even if `lexical-binding' is t. >> >> If SYMBOL's value is void and the optional argument INITVALUE is >> -provided, INITVALUE is evaluated and the result used to set SYMBOL's >> -value. If SYMBOL is buffer-local, its default value is what is set; >> +provided, INITVALUE is used to set SYMBOL's value. >> +If SYMBOL is buffer-local, its default value is what is set; >> buffer-local values are not affected. If INITVALUE is missing, >> SYMBOL's value is not set. > > This loses information, AFAIU: the previous doc string said INITVALUE > was evaluated, the new one says nothing at all about evaluating it. > If it is evaluated in some cases, please mention that; if it isn't > evaluated at all, please say that. I hesitated here. I preferred to remove the promise of when it's evaluated (which we currently break in some cases) rather than make a different promise, incompatible with the previous one. But now that Lars made me see that we actually do hold the promise in most cases, I think the better course of action is to keep the promise and fix the cases where we break it. >> -If SYMBOL has a local binding, then this form affects the local >> -binding. This is usually not what you want. Thus, if you need to >> -load a file defining variables, with this form or with `defconst' or >> -`defcustom', you should always load that file _outside_ any bindings >> -for these variables. (`defconst' and `defcustom' behave similarly in >> -this respect.) >> +If SYMBOL is let-bound, then this form does not affect the local let >> +binding but the outer (toplevel) binding. >> +(`defcustom' behaves similarly in this respect.) > > Isn't _this_ change (if it indeed constitutes a change in behavior) > scary? It was scary, yes, but that change happened back in: commit a104f656c8217b027866d32e8d7bf024a671e3cc Author: Stefan Monnier Date: Fri Aug 2 17:16:33 2013 -0400 Make defvar affect the default binding outside of any let. * src/eval.c (default_toplevel_binding): New function. (Fdefvar): Use it. (unbind_to, backtrace_eval_unrewind): Do a bit of CSE simplification. (Fdefault_toplevel_value, Fset_default_toplevel_value): New subrs. (syms_of_eval): Export them. * src/data.c (Fdefault_value): Micro cleanup. * src/term.c (init_tty): Use "false". * lisp/custom.el (custom-initialize-default, custom-initialize-set) (custom-initialize-reset, custom-initialize-changed): Affect the toplevel-default-value (bug#6275, bug#14586). * lisp/emacs-lisp/advice.el (ad-compile-function): Undo previous workaround for bug#6275. * test/automated/core-elisp-tests.el: New file. So this is just a long-overdue fix of its doc. >> +DEFUN ("defvar-f", Fdefvar_f, Sdefvar_f, 2, 3, 0, >> + doc: /* Like `defvar' but as a function. */) > > Please improve the doc string here. > >> +DEFUN ("defconst-f", Fdefconst_f, Sdefconst_f, 2, 3, 0, >> + doc: /* Like `defconst' but as a function. */) > > Likewise. How 'bout I use a double dash to make it more clear they're internal? Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 28 09:30:45 2022 Received: (at 55156) by debbugs.gnu.org; 28 Apr 2022 13:30:45 +0000 Received: from localhost ([127.0.0.1]:45800 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk4EG-0004sQ-Sz for submit@debbugs.gnu.org; Thu, 28 Apr 2022 09:30:45 -0400 Received: from quimby.gnus.org ([95.216.78.240]:54822) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk4E6-0004ro-Or for 55156@debbugs.gnu.org; Thu, 28 Apr 2022 09:30:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=6QwWmjD9Urv9X58SV07hjzLAjCJderx4vSrjtGVUSuY=; b=YEQlHiSEmsvAahxqjXbMYAPo0/ XH31LvEuI3ehEchvCzOfM5dLcAvDbQFQlzqKDxClyLe2KsHlLiKYL6SQ4WadHMXvof2HUE4SKYnB0 unaDnzc10hwTlZy+9abE9fJjziIxVgLzsBVs42fYAwotAwGzKUkuaFKwPEojZ0YdX3jk=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nk4Dw-00014U-8x; Thu, 28 Apr 2022 15:30:26 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#55156: [PATCH] eval.c: New functions `defvar-f` and `defconst-f` References: <83sfpxbwkg.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAgMAAAAqbBEUAAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAADFBMVEU2JyqVhpHKNiD/ //9bUqJDAAAAAWJLR0QDEQxM8gAAAAd0SU1FB+YEHA0dHXc0j04AAAFvSURBVCjPTdK/TsMwEAbw z1EshUyNRBmYKqbip3AkG6lMLYo9dGNAonmKiIEhEwxlNkhYyT0l5/QPvSX66S7nz1Ewp/+CvISm /c57/zXSwJ2wfhEPD5tnDQUR142wOqGEiR8GTVNtNG7h4j6HlVWVOlXc5DBiI8GYxc9a2LoSqaPj h3Z5UyF1bmKHY5XwMWRnPMUh6xbA9M5TpGV3V5SLw9gh5PcE6ntCUEhjNGRvBUI5LaAAFABvXDDO xywZmtc6GFjPWOdSChhtfc+4lrmozdrcMExV5cKZxvpHjGY1M+LVWGsZdjU3YmesyRhyt7WM2vCh YxzbnSOnpebVU9DhrpviJAzI/sFhwgn87MLygAEgCs6rI75i2HsCvfONyttL8Nj+54j7Fwrxp0fb 812vftuguNO+M8rVAEVHZH1gtGh/HZ+vsMhSZwpTFHJ7Rip1xqzmTAn8QUtbp/+gpSEFHWsnT/MZ dXN3QqpcXQDqDx9Oqg61N4v0AAAAJXRFWHRkYXRlOmNyZWF0ZQAyMDIyLTA0LTI4VDEzOjI5OjI5 KzAwOjAwP4rwBQAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMi0wNC0yOFQxMzoyOToyOSswMDowME7X SLkAAAAASUVORK5CYII= X-Now-Playing: =?utf-8?Q?R=C3=B3isin?= Murphy's =?utf-8?Q?=5FR=C3=B3isin?= Machine_: "Simulation" Date: Thu, 28 Apr 2022 15:30:23 +0200 In-Reply-To: (Stefan Monnier via's message of "Thu, 28 Apr 2022 09:26:50 -0400") Message-ID: <87pml1jpxs.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: > How 'bout I use a double dash to make it more clear they're internal? Sounds good, but perhaps also make them less crypting? I.e., something like `defvar--as-function' or something along those lines. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55156 Cc: 55156@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: > How 'bout I use a double dash to make it more clear they're internal? Sounds good, but perhaps also make them less crypting? I.e., something like `defvar--as-function' or something along those lines. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 28 09:33:35 2022 Received: (at 55156) by debbugs.gnu.org; 28 Apr 2022 13:33:35 +0000 Received: from localhost ([127.0.0.1]:45807 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk4H1-0004wn-JR for submit@debbugs.gnu.org; Thu, 28 Apr 2022 09:33:35 -0400 Received: from quimby.gnus.org ([95.216.78.240]:54844) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk4H0-0004wa-1d for 55156@debbugs.gnu.org; Thu, 28 Apr 2022 09:33:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=w1AMaTDL46WcNqPWaLM2I61ScGRXCjpHBl23q+BUGoQ=; b=PVOquOX/j5Oz+ZhBQ7pwbFU66B eh15fbIL+xemOoQrJ5Na6TXZFoNocP1IgXjnhOC0iekpPTxG1je8agtwPLingwS3MoiZb3oKfsFPb CE5AgeAHeDPJ91+jEoF6IybeeWVFmIPiKvWt7hEPIimGAxDExY2d9bfBWYxdIg6YI2GQ=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nk4Gq-00017l-I3; Thu, 28 Apr 2022 15:33:26 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#55156: [PATCH] eval.c: New functions `defvar-f` and `defconst-f` References: <83sfpxbwkg.fsf@gnu.org> <87pml1jpxs.fsf@gnus.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAgMAAAAqbBEUAAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAADFBMVEU2JyqVhpHKNiD/ //9bUqJDAAAAAWJLR0QDEQxM8gAAAAd0SU1FB+YEHA0dHXc0j04AAAFvSURBVCjPTdK/TsMwEAbw z1EshUyNRBmYKqbip3AkG6lMLYo9dGNAonmKiIEhEwxlNkhYyT0l5/QPvSX66S7nz1Ewp/+CvISm /c57/zXSwJ2wfhEPD5tnDQUR142wOqGEiR8GTVNtNG7h4j6HlVWVOlXc5DBiI8GYxc9a2LoSqaPj h3Z5UyF1bmKHY5XwMWRnPMUh6xbA9M5TpGV3V5SLw9gh5PcE6ntCUEhjNGRvBUI5LaAAFABvXDDO xywZmtc6GFjPWOdSChhtfc+4lrmozdrcMExV5cKZxvpHjGY1M+LVWGsZdjU3YmesyRhyt7WM2vCh YxzbnSOnpebVU9DhrpviJAzI/sFhwgn87MLygAEgCs6rI75i2HsCvfONyttL8Nj+54j7Fwrxp0fb 812vftuguNO+M8rVAEVHZH1gtGh/HZ+vsMhSZwpTFHJ7Rip1xqzmTAn8QUtbp/+gpSEFHWsnT/MZ dXN3QqpcXQDqDx9Oqg61N4v0AAAAJXRFWHRkYXRlOmNyZWF0ZQAyMDIyLTA0LTI4VDEzOjI5OjI5 KzAwOjAwP4rwBQAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMi0wNC0yOFQxMzoyOToyOSswMDowME7X SLkAAAAASUVORK5CYII= X-Now-Playing: =?utf-8?Q?R=C3=B3isin?= Murphy's =?utf-8?Q?=5FR=C3=B3isin?= Machine_: "Simulation" Date: Thu, 28 Apr 2022 15:33:23 +0200 In-Reply-To: <87pml1jpxs.fsf@gnus.org> (Lars Ingebrigtsen's message of "Thu, 28 Apr 2022 15:30:23 +0200") Message-ID: <87levpjpss.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Lars Ingebrigtsen writes: > Sounds good, but perhaps also make them less crypting? I.e., something > like `defvar--as-function' or something along those lines. Or even `bytecomp--defvar-as-function'. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55156 Cc: 55156@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Lars Ingebrigtsen writes: > Sounds good, but perhaps also make them less crypting? I.e., something > like `defvar--as-function' or something along those lines. Or even `bytecomp--defvar-as-function'. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 28 09:45:56 2022 Received: (at 55156) by debbugs.gnu.org; 28 Apr 2022 13:45:57 +0000 Received: from localhost ([127.0.0.1]:45856 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk4Sy-0006GO-FY for submit@debbugs.gnu.org; Thu, 28 Apr 2022 09:45:56 -0400 Received: from eggs.gnu.org ([209.51.188.92]:57736) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk4Sv-00068H-V7 for 55156@debbugs.gnu.org; Thu, 28 Apr 2022 09:45:54 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:51744) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nk4Sq-0003im-LB; Thu, 28 Apr 2022 09:45:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=LcRpwaFaPPgxZVdMKjSnL1rg7RJzRPp0DnhsJftEtEU=; b=jpTwESTCo86y 7p/BO60DFbYlzPAby6C0HQB4V1g8FBwCscqWddkPET/TdHMEVsaORdjlSbPlWU/hLBwWnUM1byyLU 8T94GzRx0pzXH/pYduOZUfE2MlXgE3fdnQjHSuhxKbMaLbVFW9s1AGTIA2DKgrwxENyj6Z96pqYJ0 C4uf+5JFIRDK+Mcc9CnEUn0RzDDFVsoMq+1bV3rlUHnR6weAuP5ve7FBMVVpvhKNkl3/2qX8H/mLQ SoE34IGzybwmf8ijfsTru9Pl0g0mT3IEkl3unXsCMcB3Yoc4b/0SGvLf6f85ycQbXM+ZahPH+wY/1 1vJxs/NXjuY9AKTjstRTaQ==; Received: from [87.69.77.57] (port=3126 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nk4Sq-00024X-55; Thu, 28 Apr 2022 09:45:48 -0400 Date: Thu, 28 Apr 2022 16:45:47 +0300 Message-Id: <83ee1hb9tg.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Thu, 28 Apr 2022 09:26:50 -0400) Subject: Re: bug#55156: [PATCH] eval.c: New functions `defvar-f` and `defconst-f` References: <83sfpxbwkg.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55156 Cc: 55156@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: 55156@debbugs.gnu.org > Date: Thu, 28 Apr 2022 09:26:50 -0400 > > >> +DEFUN ("defvar-f", Fdefvar_f, Sdefvar_f, 2, 3, 0, > >> + doc: /* Like `defvar' but as a function. */) > > > > Please improve the doc string here. > > > >> +DEFUN ("defconst-f", Fdefconst_f, Sdefconst_f, 2, 3, 0, > >> + doc: /* Like `defconst' but as a function. */) > > > > Likewise. > > How 'bout I use a double dash to make it more clear they're internal? It should still say something about its intended usage, with Emacs developers in mind, IMO. Because I doubt that we are going to document them in the ELisp reference manual, and nor do I think we should. So this place here is the only place where we can say something about these functions, so that future hackers of the byte compiler could maintain this. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 28 23:10:48 2022 Received: (at 55156) by debbugs.gnu.org; 29 Apr 2022 03:10:48 +0000 Received: from localhost ([127.0.0.1]:50397 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkH1r-0003l6-FB for submit@debbugs.gnu.org; Thu, 28 Apr 2022 23:10:48 -0400 Received: from eggs.gnu.org ([209.51.188.92]:51272) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkH1p-0003ks-Tt for 55156@debbugs.gnu.org; Thu, 28 Apr 2022 23:10:46 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:38770) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkH1k-0007ah-OJ; Thu, 28 Apr 2022 23:10:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From: mime-version; bh=K15OR9Epu0KTHQ6HwAAmcn73Q0vVvDqnEm5AbeT1RGQ=; b=ANAlbaPD2w+G gekckfxc1NfxmKjH1NbxhBRsA+YUKUThXqXsHFYSGkJDZQ+JYkjaUMFxaLAoRehuDSr9VxL7m4XZF WBGs9zis+9G6LFsNBrj8nZ3UFoDE2oaKqx9gKnwYSkXeeaXUmdXMryrpam4qaTxrX7D4xNHYG4Y70 Hbpl79jb5U8+ggcjtCxAvflwXhEFpT5gc/cqzC+4vCekCkLYBoU9YqzRE/1FeZcp9UZkEOS3bSDjE 8y/TVwbn79nfmJs1KIMSdHm5f5Vi1D+Ebz83INntE/4gN7DRYHEQjbGWym3HAYX8PQjuKEi28NCE9 9S8/XpljjDu3oadkn/I/iQ==; Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1nkH1k-0001kF-Ef; Thu, 28 Apr 2022 23:10:40 -0400 Content-Type: text/plain; charset=Utf-8 From: Richard Stallman To: Eli Zaretskii In-Reply-To: <83ee1hb9tg.fsf@gnu.org> (message from Eli Zaretskii on Thu, 28 Apr 2022 16:45:47 +0300) Subject: Re: bug#55156: [PATCH] eval.c: New functions `defvar-f` and `defconst-f` References: <83sfpxbwkg.fsf@gnu.org> <83ee1hb9tg.fsf@gnu.org> Message-Id: Date: Thu, 28 Apr 2022 23:10:40 -0400 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55156 Cc: 55156@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rms@gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] We don't have a convention of an `-f' suffix in function names. That form of name is extra cryptic. Let's choose names that follow some existing pattern rather than being inconsistent with old practice. I suggest `defvar-internal', since it isn't meant for users to call. Even `defvar-function' would be better than `defvar-f'. For the doc string, it is better to say in a self-contained way what the function does, rather than only make an analogy. How about this: Define the variable VAR, with initial value INITVAL and doc string DOC. Note that `defvar', being a special form, can distinguish between nil as INITVAL and having only one argument. However, a function cannot do that: it will treat those two cases the same. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 28 23:10:51 2022 Received: (at 55156) by debbugs.gnu.org; 29 Apr 2022 03:10:51 +0000 Received: from localhost ([127.0.0.1]:50401 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkH1v-0003lT-15 for submit@debbugs.gnu.org; Thu, 28 Apr 2022 23:10:51 -0400 Received: from eggs.gnu.org ([209.51.188.92]:51276) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkH1r-0003ku-AF for 55156@debbugs.gnu.org; Thu, 28 Apr 2022 23:10:47 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:38774) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkH1m-0007ay-22; Thu, 28 Apr 2022 23:10:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From: mime-version; bh=YcK0otTqYCT5aRuwH2vo1WhecQgyZ3BRhHu88uG62tM=; b=m4UA1JJNpR6v iIJLaWEQ0k3Jj1FLXBKv/yOe8j/nCuCJRj3dK4XliAAixSD+xWcq3pzZqCV9AHaWLbVQhNddEUdSg 7C/tfD8Vvdoe4UFVvDqNbX0FclTYwuknaS0ISb4LnlQsHJgN02ftoSBIEKiGfgi4uHZFEknIT2kZH wxm/mnm+k/AexLjoZPiN5QRdHhSoUK1nzqZKkf2Wor3BI0tivFK4AVkJrlXaBgS2TITSPF3iEyTYf SE33oR1d/pa7ZKfPShrhUaEgh878K8cPs4LZonqA2gWgdm6wgcfK0PrB32eNX1BbwfgWOqmceUxNq BZyxaaBeVif4YcbeciDR6w==; Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1nkH1l-0001l8-Nb; Thu, 28 Apr 2022 23:10:41 -0400 Content-Type: text/plain; charset=Utf-8 From: Richard Stallman To: Eli Zaretskii In-Reply-To: <83r15hbw47.fsf@gnu.org> (message from Eli Zaretskii on Thu, 28 Apr 2022 08:44:08 +0300) Subject: Re: bug#55156: [PATCH] eval.c: New functions `defvar-f` and `defconst-f` References: <87tuaep47a.fsf@gnus.org> <87pml2p35g.fsf@gnus.org> <83r15hbw47.fsf@gnu.org> Message-Id: Date: Thu, 28 Apr 2022 23:10:41 -0400 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55156 Cc: 55156@debbugs.gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rms@gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > I sincerely question the wisdom of messing with this, for the reasons > that were described, which seem to be some inelegant code somewhere in > the bowels of the byte compiler. Do we really care enough about such > inelegance to make potentially breaking changes in code that works for > decades and causes zero trouble to Lisp programmers? I feel the same. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 28 23:10:51 2022 Received: (at 55156) by debbugs.gnu.org; 29 Apr 2022 03:10:51 +0000 Received: from localhost ([127.0.0.1]:50403 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkH1v-0003lW-9p for submit@debbugs.gnu.org; Thu, 28 Apr 2022 23:10:51 -0400 Received: from eggs.gnu.org ([209.51.188.92]:51288) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkH1r-0003kw-OC for 55156@debbugs.gnu.org; Thu, 28 Apr 2022 23:10:48 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:38776) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkH1m-0007bA-IP; Thu, 28 Apr 2022 23:10:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From: mime-version; bh=ZPxVbzDf9XQwzYLHaTIvtmKWSwz99NO0YTDgTF9k9hE=; b=QeLhBikdnkY/ 3Cdgac1biobaKqK0glHkhc13JztBxt+e/E+A6B4BjpUgQii/HEiJ3dRtFoZFM/joghZzD3XdecxWp g1vWfu6D6kKTynCe4THfmXUcwDvoui+V8K4UV+ALYRDAcT95wOMYhZnZ1TUQS19hfQOipZZwWpOJ2 WQfje+g63RgvRbdnClaC2ZihCAEwxkILWCVrt30ZQx6m/sXiHEU8vj9c5YE5b/uYDzhHkIK8WUE7I wzwpiaFk2PVMLEi/h/3VMnPNVvSxr9e9pFoVB41FSR0dRWXmATckSddrfszlqFyV6hCNaP89MqDPf casQahUAZ58W3EDJoGFVOw==; Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1nkH1m-0001lO-9E; Thu, 28 Apr 2022 23:10:42 -0400 Content-Type: text/plain; charset=Utf-8 From: Richard Stallman To: Stefan Monnier In-Reply-To: (bug-gnu-emacs@gnu.org) Subject: Re: bug#55156: [PATCH] eval.c: New functions `defvar-f` and `defconst-f` References: Message-Id: Date: Thu, 28 Apr 2022 23:10:42 -0400 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55156 Cc: 55156@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rms@gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > This sounds scary, but the reality is less so: while the behavior of > the special form obeyed its doc in this respect, the behavior of the > convoluted code generated by the byte-compiler did not(!) and always > evaluated the part anyway. So this patch also aligns the two > semantics to provide the same behavior. I have a feeling that that discrepancy will cause real trouble some day. However, fixing it can cause trouble too. I think this calls for real thought. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) From debbugs-submit-bounces@debbugs.gnu.org Wed May 25 16:38:58 2022 Received: (at 55156) by debbugs.gnu.org; 25 May 2022 20:38:58 +0000 Received: from localhost ([127.0.0.1]:56507 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ntxmT-0004yE-JW for submit@debbugs.gnu.org; Wed, 25 May 2022 16:38:58 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:35471) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ntxmQ-0004xu-Hj for 55156@debbugs.gnu.org; Wed, 25 May 2022 16:38:55 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id C1A418080E; Wed, 25 May 2022 16:38:48 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 889EB802A7; Wed, 25 May 2022 16:38:46 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1653511126; bh=F2mOC9lIOnphlGvgHN7xgIT4trrGGArxUQRGkV44+qI=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=BhmJgwK8MKjttIkh3Dq1LZ6s2dwJuuwLD21IesZ06ut+SfGoQzM0gHUGx01y7UD7Z QSS7AQd7orxPH/bYLuVMXrHaIGY6i1vKNOOVj8XIuYTweuSvCrVzaCjjFJHaIldUjs xYjj+wNWErrOLCvU7GsEwMpZHAm5RKBXI1QYO9AaL+Cpuy+atcWV+1MwLMUGQdrEfb JUNxxJlrZrSk120vGp1CfkNx2smGnFzrSgy+W92R8oAcdZ58XTMlIDDqhEiuk9sFKt YvjCBREDwXoJHlHcV0fYuOAienR+Ykyh9NyXsS0HWQmB0jZrQ2g9dIcnfYTBY7I+Yh oWkM63wRWwViA== Received: from alfajor (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 73A5E120A16; Wed, 25 May 2022 16:38:46 -0400 (EDT) From: Stefan Monnier To: 55156@debbugs.gnu.org Subject: Re: bug#55156: [PATCH] eval.c: New functions `defvar-f` and `defconst-f` Message-ID: References: <83sfpxbwkg.fsf@gnu.org> Date: Wed, 25 May 2022 16:38:45 -0400 In-Reply-To: <83sfpxbwkg.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 28 Apr 2022 08:34:23 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.206 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55156 Cc: Eli Zaretskii , Lars Ingebrigtsen X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Here's a new version of my patch. Most importantly the "defvar function" now only assigns the value to the var if the var was not already defined (i.e. it keeps the current behavior). > What is "dynamic outer value"? We don't have such terminology > anywhere in the manual. I changed it to use the same terminology as `set-toplevel-default-binding` (and to refer to that as well). > This loses information, AFAIU: the previous doc string said INITVALUE > was evaluated, the new one says nothing at all about evaluating it. > If it is evaluated in some cases, please mention that; if it isn't > evaluated at all, please say that. I reverted this part of the change. >> -If SYMBOL has a local binding, then this form affects the local >> -binding. This is usually not what you want. Thus, if you need to >> -load a file defining variables, with this form or with `defconst' or >> -`defcustom', you should always load that file _outside_ any bindings >> -for these variables. (`defconst' and `defcustom' behave similarly in >> -this respect.) >> +If SYMBOL is let-bound, then this form does not affect the local let >> +binding but the outer (toplevel) binding. >> +(`defcustom' behaves similarly in this respect.) > > Isn't _this_ change (if it indeed constitutes a change in behavior) > scary? It's only a change in the doc (the corresponding code change took place several years ago). >> +DEFUN ("defvar-f", Fdefvar_f, Sdefvar_f, 2, 3, 0, >> + doc: /* Like `defvar' but as a function. */) > Please improve the doc string here. I added a line which defines it precisely in terms of `defvar`. Richard Stallman [2022-04-28 23:10:40] wrote: > We don't have a convention of an `-f' suffix in function names. > That form of name is extra cryptic. > Let's choose names that follow some existing pattern > rather than being inconsistent with old practice. I see that at various other places where we have a macro expand to a call to an "internal" function, we name that function with a "-1" suffix, so I decided to follow that convention. Stefan The bytecode interpreter can't directly call special forms, so the byte-compiler usually converts special forms into some sequence of byte codes (basically, providing a duplicate definition of the special form). There are still two exceptions to this: `defconst` and `defvar`, where the compiler instead generates a convoluted chunk of code like: (funcall '(lambda (x) (defvar x )) ) where the quote makes sure we keep the function non-compiled, so as to end up running the special form at run time. The patch below gets rid of this workaround by introducing `defvar-1` and `defconst-1` which provide a *functional* interface to the functionality of the corresponding special form. * src/eval.c (defvar, Fdefvar_1, Fdefconst_1): New functions, extracted from `Fdef(var|const)`. (Fdefvar, Fdefconst): Use them. (syms_of_eval): `defsubr` the new functions. * lisp/emacs-lisp/bytecomp.el (byte-compile-tmp-var): Delete const. (byte-compile-defvar): Simplify using the new `def(car|const)-1` functions. * doc/lispref/variables.texi (Defining Variables): Adjust the doc of `defvar` to reflect the actual semantics implemented. diff --git a/doc/lispref/variables.texi b/doc/lispref/variables.texi index f0e3f337a69..c29547d00db 100644 --- a/doc/lispref/variables.texi +++ b/doc/lispref/variables.texi @@ -527,10 +527,11 @@ Defining Variables rather than the buffer-local binding. It sets the default value if the default value is void. @xref{Buffer-Local Variables}. -If @var{symbol} is already lexically bound (e.g., if the @code{defvar} -form occurs in a @code{let} form with lexical binding enabled), then -@code{defvar} sets the dynamic value. The lexical binding remains in -effect until its binding construct exits. @xref{Variable Scoping}. +If @var{symbol} is already let bound (e.g., if the @code{defvar} +form occurs in a @code{let} form), then @code{defvar} sets the toplevel +default value, like @code{set-default-toplevel-value}. +The let binding remains in effect until its binding construct exits. +@xref{Variable Scoping}. @cindex @code{eval-defun}, and @code{defvar} forms @cindex @code{eval-last-sexp}, and @code{defvar} forms diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el index 87798288fb5..b07e7b4e57f 100644 --- a/lisp/emacs-lisp/bytecomp.el +++ b/lisp/emacs-lisp/bytecomp.el @@ -4948,8 +4948,6 @@ byte-compile-make-obsolete-variable (push (nth 1 (nth 1 form)) byte-compile-global-not-obsolete-vars)) (byte-compile-normal-call form)) -(defconst byte-compile-tmp-var (make-symbol "def-tmp-var")) - (defun byte-compile-defvar (form) ;; This is not used for file-level defvar/consts. (when (and (symbolp (nth 1 form)) @@ -4962,7 +4960,6 @@ byte-compile-defvar (byte-compile-docstring-style-warn form) (let ((fun (nth 0 form)) (var (nth 1 form)) - (value (nth 2 form)) (string (nth 3 form))) (when (or (> (length form) 4) (and (eq fun 'defconst) (null (cddr form)))) @@ -4982,18 +4979,16 @@ byte-compile-defvar string "third arg to `%s %s' is not a string: %s" fun var string)) + ;; Delegate the actual work to the function version of the + ;; special form, named with a "-1" suffix. (byte-compile-form-do-effect - (if (cddr form) ; `value' provided - ;; Quote with `quote' to prevent byte-compiling the body, - ;; which would lead to an inf-loop. - `(funcall '(lambda (,byte-compile-tmp-var) - (,fun ,var ,byte-compile-tmp-var ,@(nthcdr 3 form))) - ,value) - (if (eq fun 'defconst) - ;; This will signal an appropriate error at runtime. - `(eval ',form) - ;; A simple (defvar foo) just returns foo. - `',var))))) + (cond + ((eq fun 'defconst) `(defconst-1 ',var ,@(nthcdr 2 form))) + ((not (cddr form)) `',var) ; A simple (defvar foo) just returns foo. + (t `(defvar-1 ',var + ;; Don't eval `value' if `defvar' wouldn't eval it either. + (if (boundp ',var) nil ,(nth 2 form)) + ,@(nthcdr 3 form))))))) (defun byte-compile-autoload (form) (and (macroexp-const-p (nth 1 form)) diff --git a/src/eval.c b/src/eval.c index 08e2dce61e4..c3be1dc12c8 100644 --- a/src/eval.c +++ b/src/eval.c @@ -756,6 +756,33 @@ DEFUN ("internal--define-uninitialized-variable", return Qnil; } +static Lisp_Object +defvar (Lisp_Object sym, Lisp_Object initvalue, Lisp_Object docstring, bool eval) +{ + Lisp_Object tem; + + CHECK_SYMBOL (sym); + + tem = Fdefault_boundp (sym); + + /* Do it before evaluating the initial value, for self-references. */ + Finternal__define_uninitialized_variable (sym, docstring); + + if (NILP (tem)) + Fset_default (sym, eval ? eval_sub (initvalue) : initvalue); + else + { /* Check if there is really a global binding rather than just a let + binding that shadows the global unboundness of the var. */ + union specbinding *binding = default_toplevel_binding (sym); + if (binding && EQ (specpdl_old_value (binding), Qunbound)) + { + set_specpdl_old_value (binding, + eval ? eval_sub (initvalue) : initvalue); + } + } + return sym; +} + DEFUN ("defvar", Fdefvar, Sdefvar, 1, UNEVALLED, 0, doc: /* Define SYMBOL as a variable, and return SYMBOL. You are not required to define a variable in order to use it, but @@ -770,12 +797,10 @@ DEFUN ("defvar", Fdefvar, Sdefvar, 1, UNEVALLED, 0, buffer-local values are not affected. If INITVALUE is missing, SYMBOL's value is not set. -If SYMBOL has a local binding, then this form affects the local -binding. This is usually not what you want. Thus, if you need to -load a file defining variables, with this form or with `defconst' or -`defcustom', you should always load that file _outside_ any bindings -for these variables. (`defconst' and `defcustom' behave similarly in -this respect.) +If SYMBOL is let-bound, then this form does not affect the local let +binding but the toplevel default binding instead, like +`set-toplevel-default-binding`. +(`defcustom' behaves similarly in this respect.) The optional argument DOCSTRING is a documentation string for the variable. @@ -786,7 +811,7 @@ DEFUN ("defvar", Fdefvar, Sdefvar, 1, UNEVALLED, 0, usage: (defvar SYMBOL &optional INITVALUE DOCSTRING) */) (Lisp_Object args) { - Lisp_Object sym, tem, tail; + Lisp_Object sym, tail; sym = XCAR (args); tail = XCDR (args); @@ -798,24 +823,8 @@ DEFUN ("defvar", Fdefvar, Sdefvar, 1, UNEVALLED, 0, if (!NILP (XCDR (tail)) && !NILP (XCDR (XCDR (tail)))) error ("Too many arguments"); Lisp_Object exp = XCAR (tail); - - tem = Fdefault_boundp (sym); tail = XCDR (tail); - - /* Do it before evaluating the initial value, for self-references. */ - Finternal__define_uninitialized_variable (sym, CAR (tail)); - - if (NILP (tem)) - Fset_default (sym, eval_sub (exp)); - else - { /* Check if there is really a global binding rather than just a let - binding that shadows the global unboundness of the var. */ - union specbinding *binding = default_toplevel_binding (sym); - if (binding && EQ (specpdl_old_value (binding), Qunbound)) - { - set_specpdl_old_value (binding, eval_sub (exp)); - } - } + return defvar (sym, exp, CAR (tail), true); } else if (!NILP (Vinternal_interpreter_environment) && (SYMBOLP (sym) && !XSYMBOL (sym)->u.s.declared_special)) @@ -834,6 +843,14 @@ DEFUN ("defvar", Fdefvar, Sdefvar, 1, UNEVALLED, 0, return sym; } +DEFUN ("defvar-1", Fdefvar_1, Sdefvar_1, 2, 3, 0, + doc: /* Like `defvar' but as a function. +More specifically behaves like (defvar SYM 'INITVALUE DOCSTRING). */) + (Lisp_Object sym, Lisp_Object initvalue, Lisp_Object docstring) +{ + return defvar (sym, initvalue, docstring, false); +} + DEFUN ("defconst", Fdefconst, Sdefconst, 2, UNEVALLED, 0, doc: /* Define SYMBOL as a constant variable. This declares that neither programs nor users should ever change the @@ -863,9 +880,18 @@ DEFUN ("defconst", Fdefconst, Sdefconst, 2, UNEVALLED, 0, error ("Too many arguments"); docstring = XCAR (XCDR (XCDR (args))); } + tem = eval_sub (XCAR (XCDR (args))); + return Fdefconst_1 (sym, tem, docstring); +} +DEFUN ("defconst-1", Fdefconst_1, Sdefconst_1, 2, 3, 0, + doc: /* Like `defconst' but as a function. +More specifically, behaves like (defconst SYM 'INITVALUE DOCSTRING). */) + (Lisp_Object sym, Lisp_Object initvalue, Lisp_Object docstring) +{ + CHECK_SYMBOL (sym); + Lisp_Object tem = initvalue; Finternal__define_uninitialized_variable (sym, docstring); - tem = eval_sub (XCAR (XCDR (args))); if (!NILP (Vpurify_flag)) tem = Fpurecopy (tem); Fset_default (sym, tem); /* FIXME: set-default-toplevel-value? */ @@ -4333,9 +4359,11 @@ syms_of_eval (void) defsubr (&Sdefault_toplevel_value); defsubr (&Sset_default_toplevel_value); defsubr (&Sdefvar); + defsubr (&Sdefvar_1); defsubr (&Sdefvaralias); DEFSYM (Qdefvaralias, "defvaralias"); defsubr (&Sdefconst); + defsubr (&Sdefconst_1); defsubr (&Sinternal__define_uninitialized_variable); defsubr (&Smake_var_non_special); defsubr (&Slet); From debbugs-submit-bounces@debbugs.gnu.org Thu May 26 01:01:54 2022 Received: (at 55156) by debbugs.gnu.org; 26 May 2022 05:01:54 +0000 Received: from localhost ([127.0.0.1]:56843 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nu5dC-0004mW-JG for submit@debbugs.gnu.org; Thu, 26 May 2022 01:01:54 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44932) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nu5d7-0004mD-BJ for 55156@debbugs.gnu.org; Thu, 26 May 2022 01:01:52 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:56032) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nu5d2-0006qS-0U; Thu, 26 May 2022 01:01:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=6QqB78JbM+e/wtfSTpWJ7XvEFBtlZvFmttIT6cpfmgw=; b=PbLSxV9n2yJD 81rhuZ5W9VNK0I3dLVLi6JbN0EUPPDALoM6pSASh9ba0yYuUTNSzpgumGs5Z8TrvSntf/RqVdwdYJ AW3XN1qtLe7BgCTIPfV+Xx0IYSqfAhSRS6BH3sPLWRexaXIlzFExZ1+iYlwdzqNI9WJXz2moFcMoA GajMQRI5iZKeMTnFgVTuvLaJYCSjEUXTgDn/RrRwTup8V8pAmODXQh4LrTznhMuykQB+JNDXW+krb Axlnvf0Ta3y+hrzjH5AhO2jgk+24peONUVZn4+SWyIi9cTEzV5pBvTwnocnMVjF9MxjCgkbmteqZn /si5rj3ZoaCy9NCdY6vqbw==; Received: from [87.69.77.57] (port=2979 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nu5cu-0002P7-IC; Thu, 26 May 2022 01:01:41 -0400 Date: Thu, 26 May 2022 08:01:27 +0300 Message-Id: <83leuoq448.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Wed, 25 May 2022 16:38:45 -0400) Subject: Re: bug#55156: [PATCH] eval.c: New functions `defvar-f` and `defconst-f` References: <83sfpxbwkg.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55156 Cc: 55156@debbugs.gnu.org, larsi@gnus.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: Eli Zaretskii , Lars Ingebrigtsen > Date: Wed, 25 May 2022 16:38:45 -0400 LGTM, with a minor nit: > * src/eval.c (defvar, Fdefvar_1, Fdefconst_1): New functions, extracted from > `Fdef(var|const)`. ^^^^^^^^^^^ [...] > (byte-compile-defvar): Simplify using the new `def(car|const)-1` functions. ^^^^^^^^^^^ Can we please not use such "shorthands" in the log messages? They make it much harder to search for changes related to some symbol, and much easier to miss some changes. I understand the urge to type less, but M-/ is available to alleviate that, and usually does the job for me. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Thu May 26 21:27:46 2022 Received: (at 55156-done) by debbugs.gnu.org; 27 May 2022 01:27:46 +0000 Received: from localhost ([127.0.0.1]:60337 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nuOlW-00043r-LC for submit@debbugs.gnu.org; Thu, 26 May 2022 21:27:46 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:61265) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nuOlV-00043e-GT for 55156-done@debbugs.gnu.org; Thu, 26 May 2022 21:27:45 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 13C3F8067B; Thu, 26 May 2022 21:27:40 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id B9E9980658; Thu, 26 May 2022 21:27:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1653614854; bh=OQ/q+KbpcJNiNdA5/4keDmqxoQn0ssk8WdsgnVHnyfU=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=GYQTXfESU0HSj7HFjQgBgmY3X2knxBNMWlFb0MJIm3hG/9qoxULCjZDFdb5peegeS ZOIEG78euKjNUIh4Yc/May/2ebOhFyAuDW8vbOXacsKWh1LPZupLsL0OWYWT7AVz46 aY1RbaImu/q2eHbX+P7VeDP4Pz0/3moMvlbIXHHjzHhYQfj2EgpOQzvwR5LUuAaqcI htEuTWfbMwXWJwo6akE7voSIJ1EHbAzVve/3p618y7rNh+GFzuYMSHWkWy/eaFRDPn 5Y7OUchMTVxj3+SUM3b/+P8F3IxfDEOPlF4qH9k8bxScYdQvWZECU0YnZ2x2JRZ5lL RyiCj5rZu5nSQ== Received: from pastel (unknown [45.72.221.51]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 5D64D120176; Thu, 26 May 2022 21:27:34 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#55156: [PATCH] eval.c: New functions `defvar-f` and `defconst-f` Message-ID: References: <83sfpxbwkg.fsf@gnu.org> <83leuoq448.fsf@gnu.org> Date: Thu, 26 May 2022 21:27:33 -0400 In-Reply-To: <83leuoq448.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 26 May 2022 08:01:27 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.054 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55156-done Cc: larsi@gnus.org, 55156-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> (byte-compile-defvar): Simplify using the new `def(car|const)-1` functions. > ^^^^^^^^^^^ > Can we please not use such "shorthands" in the log messages? Fixed, and then pushed, thanks, Stefan From unknown Sun Jun 22 19:06:34 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 24 Jun 2022 11:24:07 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator