GNU bug report logs - #55156
[PATCH] eval.c: New functions `defvar-f` and `defconst-f`

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: Stefan Monnier <monnier@HIDDEN>; Keywords: patch; dated Wed, 27 Apr 2022 21:47:01 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 55156 <at> debbugs.gnu.org:


Received: (at 55156) by debbugs.gnu.org; 28 Apr 2022 13:45:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 28 09:45:56 2022
Received: from localhost ([127.0.0.1]:45856 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nk4Sy-0006GO-FY
	for submit <at> 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 <eliz@HIDDEN>) id 1nk4Sv-00068H-V7
 for 55156 <at> 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 <eliz@HIDDEN>)
 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 <eliz@HIDDEN>)
 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@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <jwvr15hic1a.fsf-monnier+emacs@HIDDEN> (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: <jwvh76ejj2p.fsf@HIDDEN> <83sfpxbwkg.fsf@HIDDEN>
 <jwvr15hic1a.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 55156
Cc: 55156 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: 55156 <at> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#55156; Package emacs. Full text available.

Message received at 55156 <at> debbugs.gnu.org:


Received: (at 55156) by debbugs.gnu.org; 28 Apr 2022 13:33:35 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 28 09:33:35 2022
Received: from localhost ([127.0.0.1]:45807 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nk4H1-0004wn-JR
	for submit <at> 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 <larsi@HIDDEN>) id 1nk4H0-0004wa-1d
 for 55156 <at> 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 <larsi@HIDDEN>)
 id 1nk4Gq-00017l-I3; Thu, 28 Apr 2022 15:33:26 +0200
From: Lars Ingebrigtsen <larsi@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#55156: [PATCH] eval.c: New functions `defvar-f` and
 `defconst-f`
References: <jwvh76ejj2p.fsf@HIDDEN> <83sfpxbwkg.fsf@HIDDEN>
 <jwvr15hic1a.fsf-monnier+emacs@HIDDEN> <87pml1jpxs.fsf@HIDDEN>
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@HIDDEN> (Lars Ingebrigtsen's message of "Thu,
 28 Apr 2022 15:30:23 +0200")
Message-ID: <87levpjpss.fsf@HIDDEN>
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 <larsi@HIDDEN> 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 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Lars Ingebrigtsen <larsi@HIDDEN> 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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#55156; Package emacs. Full text available.

Message received at 55156 <at> debbugs.gnu.org:


Received: (at 55156) by debbugs.gnu.org; 28 Apr 2022 13:30:45 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 28 09:30:45 2022
Received: from localhost ([127.0.0.1]:45800 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nk4EG-0004sQ-Sz
	for submit <at> 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 <larsi@HIDDEN>) id 1nk4E6-0004ro-Or
 for 55156 <at> 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 <larsi@HIDDEN>)
 id 1nk4Dw-00014U-8x; Thu, 28 Apr 2022 15:30:26 +0200
From: Lars Ingebrigtsen <larsi@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#55156: [PATCH] eval.c: New functions `defvar-f` and
 `defconst-f`
References: <jwvh76ejj2p.fsf@HIDDEN> <83sfpxbwkg.fsf@HIDDEN>
 <jwvr15hic1a.fsf-monnier+emacs@HIDDEN>
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: <jwvr15hic1a.fsf-monnier+emacs@HIDDEN> (Stefan Monnier via's
 message of "Thu, 28 Apr 2022 09:26:50 -0400")
Message-ID: <87pml1jpxs.fsf@HIDDEN>
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" <bug-gnu-emacs@HIDDEN> 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 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@HIDDEN> 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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#55156; Package emacs. Full text available.

Message received at 55156 <at> debbugs.gnu.org:


Received: (at 55156) by debbugs.gnu.org; 28 Apr 2022 13:27:00 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 28 09:27:00 2022
Received: from localhost ([127.0.0.1]:45781 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nk4Ae-0004l6-6g
	for submit <at> 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 <monnier@HIDDEN>) id 1nk4Ac-0004ku-OL
 for 55156 <at> 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 <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#55156: [PATCH] eval.c: New functions `defvar-f` and
 `defconst-f`
Message-ID: <jwvr15hic1a.fsf-monnier+emacs@HIDDEN>
References: <jwvh76ejj2p.fsf@HIDDEN> <83sfpxbwkg.fsf@HIDDEN>
Date: Thu, 28 Apr 2022 09:26:50 -0400
In-Reply-To: <83sfpxbwkg.fsf@HIDDEN> (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 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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 <monnier@HIDDEN>
    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





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#55156; Package emacs. Full text available.

Message received at 55156 <at> debbugs.gnu.org:


Received: (at 55156) by debbugs.gnu.org; 28 Apr 2022 05:44:18 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 28 01:44:18 2022
Received: from localhost ([127.0.0.1]:44981 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1njwws-0004MB-Hv
	for submit <at> 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 <eliz@HIDDEN>) id 1njwwr-0004M0-CW
 for 55156 <at> 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 <eliz@HIDDEN>)
 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 <eliz@HIDDEN>)
 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@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Lars Ingebrigtsen <larsi@HIDDEN>
In-Reply-To: <87pml2p35g.fsf@HIDDEN> (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: <jwvh76ejj2p.fsf@HIDDEN> <87tuaep47a.fsf@HIDDEN>
 <jwv1qxiyxs8.fsf-monnier+emacs@HIDDEN> <87pml2p35g.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 55156
Cc: 55156 <at> debbugs.gnu.org, monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Lars Ingebrigtsen <larsi@HIDDEN>
> Date: Thu, 28 Apr 2022 00:33:47 +0200
> Cc: 55156 <at> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#55156; Package emacs. Full text available.

Message received at 55156 <at> debbugs.gnu.org:


Received: (at 55156) by debbugs.gnu.org; 28 Apr 2022 05:34:32 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 28 01:34:32 2022
Received: from localhost ([127.0.0.1]:44975 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1njwnQ-000483-DW
	for submit <at> 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 <eliz@HIDDEN>) id 1njwnP-00047r-28
 for 55156 <at> 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 <eliz@HIDDEN>)
 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 <eliz@HIDDEN>)
 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@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <jwvh76ejj2p.fsf@HIDDEN> (bug-gnu-emacs@HIDDEN)
Subject: Re: bug#55156: [PATCH] eval.c: New functions `defvar-f` and
 `defconst-f`
References: <jwvh76ejj2p.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 55156
Cc: 55156 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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" <bug-gnu-emacs@HIDDEN>
> 
> 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 <sym> x <doc>)) <value>)
> 
> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#55156; Package emacs. Full text available.

Message received at 55156 <at> debbugs.gnu.org:


Received: (at 55156) by debbugs.gnu.org; 28 Apr 2022 01:30:02 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Apr 27 21:30:02 2022
Received: from localhost ([127.0.0.1]:44775 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1njsyf-00063y-1u
	for submit <at> 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 <monnier@HIDDEN>) id 1njsyZ-00063j-PO
 for 55156 <at> 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 <monnier@HIDDEN>
To: Lars Ingebrigtsen <larsi@HIDDEN>
Subject: Re: bug#55156: [PATCH] eval.c: New functions `defvar-f` and
 `defconst-f`
Message-ID: <jwvilquj8sh.fsf-monnier+emacs@HIDDEN>
References: <jwvh76ejj2p.fsf@HIDDEN> <87tuaep47a.fsf@HIDDEN>
 <jwv1qxiyxs8.fsf-monnier+emacs@HIDDEN> <87pml2p35g.fsf@HIDDEN>
Date: Wed, 27 Apr 2022 21:29:34 -0400
In-Reply-To: <87pml2p35g.fsf@HIDDEN> (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 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#55156; Package emacs. Full text available.

Message received at 55156 <at> debbugs.gnu.org:


Received: (at 55156) by debbugs.gnu.org; 27 Apr 2022 22:34:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Apr 27 18:34:03 2022
Received: from localhost ([127.0.0.1]:44730 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1njqEV-0007Vs-AA
	for submit <at> 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 <larsi@HIDDEN>) id 1njqET-0007VM-4x
 for 55156 <at> 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 <larsi@HIDDEN>)
 id 1njqEI-0001mq-VX; Thu, 28 Apr 2022 00:33:53 +0200
From: Lars Ingebrigtsen <larsi@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: Re: bug#55156: [PATCH] eval.c: New functions `defvar-f` and
 `defconst-f`
References: <jwvh76ejj2p.fsf@HIDDEN> <87tuaep47a.fsf@HIDDEN>
 <jwv1qxiyxs8.fsf-monnier+emacs@HIDDEN>
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: <jwv1qxiyxs8.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message
 of "Wed, 27 Apr 2022 18:29:38 -0400")
Message-ID: <87pml2p35g.fsf@HIDDEN>
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 <monnier@HIDDEN> writes: >> Uhm --
 are you saying that if you load an .elc file twice, the <exp> >> 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 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Stefan Monnier <monnier@HIDDEN> writes:

>> Uhm -- are you saying that if you load an .elc file twice, the <exp>
>> 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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#55156; Package emacs. Full text available.

Message received at 55156 <at> debbugs.gnu.org:


Received: (at 55156) by debbugs.gnu.org; 27 Apr 2022 22:29:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Apr 27 18:29:49 2022
Received: from localhost ([127.0.0.1]:44723 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1njqAO-0007NB-Op
	for submit <at> 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 <monnier@HIDDEN>) id 1njqAM-0007My-Bs
 for 55156 <at> 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 <monnier@HIDDEN>
To: Lars Ingebrigtsen <larsi@HIDDEN>
Subject: Re: bug#55156: [PATCH] eval.c: New functions `defvar-f` and
 `defconst-f`
Message-ID: <jwv1qxiyxs8.fsf-monnier+emacs@HIDDEN>
References: <jwvh76ejj2p.fsf@HIDDEN> <87tuaep47a.fsf@HIDDEN>
Date: Wed, 27 Apr 2022 18:29:38 -0400
In-Reply-To: <87tuaep47a.fsf@HIDDEN> (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 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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" <bug-gnu-emacs@HIDDEN> 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 <exp> 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 <exp>
> 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





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#55156; Package emacs. Full text available.

Message received at 55156 <at> debbugs.gnu.org:


Received: (at 55156) by debbugs.gnu.org; 27 Apr 2022 22:11:18 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Apr 27 18:11:18 2022
Received: from localhost ([127.0.0.1]:44699 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1njpsT-0006s2-PL
	for submit <at> 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 <larsi@HIDDEN>) id 1njpsS-0006rl-DD
 for 55156 <at> 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 <larsi@HIDDEN>)
 id 1njpsI-0001dS-52; Thu, 28 Apr 2022 00:11:08 +0200
From: Lars Ingebrigtsen <larsi@HIDDEN>
To: 55156 <at> debbugs.gnu.org
Subject: Re: bug#55156: [PATCH] eval.c: New functions `defvar-f` and
 `defconst-f`
References: <jwvh76ejj2p.fsf@HIDDEN>
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: <jwvh76ejj2p.fsf@HIDDEN> (Stefan Monnier via's message
 of "Wed, 27 Apr 2022 17:46:22 -0400")
Message-ID: <87tuaep47a.fsf@HIDDEN>
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" <bug-gnu-emacs@HIDDEN> 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 <monnier@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@HIDDEN> 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 <exp> 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 <exp>
parts in the defvars will be evaluated twice?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#55156; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 27 Apr 2022 21:46:47 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Apr 27 17:46:46 2022
Received: from localhost ([127.0.0.1]:44653 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1njpUk-0006A5-83
	for submit <at> 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 <monnier@HIDDEN>) id 1njpUi-00069x-NP
 for submit <at> 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 <monnier@HIDDEN>)
 id 1njpUi-0006bY-BW
 for bug-gnu-emacs@HIDDEN; 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 <monnier@HIDDEN>)
 id 1njpUe-0005Tf-Pt
 for bug-gnu-emacs@HIDDEN; 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 <bug-gnu-emacs@HIDDEN>; 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 <bug-gnu-emacs@HIDDEN>; 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 <bug-gnu-emacs@HIDDEN>; Wed, 27 Apr 2022 17:46:36 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: [PATCH] eval.c: New functions `defvar-f` and `defconst-f`
Date: Wed, 27 Apr 2022 17:46:22 -0400
Message-ID: <jwvh76ejj2p.fsf@HIDDEN>
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@HIDDEN; 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 <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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 <monnier@HIDDEN>
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 <sym> x <doc>)) <value>)

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 <sym> <exp>) because
(defvar-f '<sym> <exp>) will now always evaluate <exp> whereas
previously the doc promised that <exp> would only be evaluated if
<sym> 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 <exp> 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


--=-=-=--





Acknowledgement sent to Stefan Monnier <monnier@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#55156; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Thu, 28 Apr 2022 14:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.