From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: master de6b1e1efb1: Replace XSETSYMBOL with make_lisp_symbol Date: Sun, 03 Mar 2024 08:52:09 +0200 Message-ID: <86zfvfolie.fsf@gnu.org> References: <86plwlyb5a.fsf@gnu.org> <86il2dxf7h.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17332"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Mar 03 07:53:13 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rgfij-0004G6-HG for ged-emacs-devel@m.gmane-mx.org; Sun, 03 Mar 2024 07:53:13 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rgfhp-0008DK-ER; Sun, 03 Mar 2024 01:52:17 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rgfhk-0008Cs-Lk for emacs-devel@gnu.org; Sun, 03 Mar 2024 01:52:12 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rgfhk-0005eK-5o; Sun, 03 Mar 2024 01:52:12 -0500 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=/6hJazRnf11TKqDX1EJqMbuXPgdjHrZi+aQOoOM9NWo=; b=rHxvVJh18GxH evjOFtXhm+f0M/h1IThbFQEZWuzVMzrtx2Qywsc/AsA+yCcPY+4fD8EYq0zU3npuHRCugTFxBW+8G t+oz4IaMmVEl/Tg1bKAGLVxJK628xIXugskZSufkJ8ry+Hb312Pu0hir6A6OlS7O8Is/ohqIyfEbp DLLcL9lLXQlE85bJRiJnjW1X6Q8S8ZnzmQhsVIBYuTQUXjVhPba/bXiEYXJYzndhQ9QDmY3Yv/vtD B/T+Wc/SgqCJQAFkwiSN2U1yyZJSgtmTeHtBR2ApRuMCUfpwC0gchmvU11u/eMVTrnfDC3E4qQH69 RUHDj3G6ANvnLPZ7Uc5XNg==; In-Reply-To: (emacs-devel@gnu.org) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:316726 Archived-At: > Date: Sat, 02 Mar 2024 16:57:28 -0500 > From: Stefan Monnier via "Emacs development discussions." > > >> More in detail, `a=f(b)` is inherently simpler, more transparent, concise > >> and composable than `X(a,b)`. It is obvious to the reader that it's an > >> assignment and that `a` is only modified, `b` not at all and is only > >> evaluated once. There is no need for an assignment at all if the result is > >> used elsewhere. > > > > This is your stylistic preference, which I don't share, probably > > because I'm biased by many years of staring on Emacs code that uses > > such macros everywhere. > > I don't have a strong opinion about whether we should keep the XSETFOO > style of macros, but I've been annoyed several times in the past at the > need to introduce a "tmp" local var just to do > > XSETFOO (tmp, mything); > ... tmp ... > > which can turn from merely inconvenient and ugly to almost impossible > when such code needs to be used in an expression macro, which we can't > really introduce such local variables. For that reason, I started > using `make_lisp_ptr` and things along these lines. I understand this as a general principle and share it, to a degree. But it is a weak reason, and so in this case the muscle memory takes precedence. I'm still recovering from the XINT/XFASTINT/XSETINT/XFIXNUM/XFIXNAT change, but in that case it was at least justified by the addition of bignums. So I'd like to revert this changeset, and I'm asking everyone to please not remove the XSET* macros unless we are adding new types or redesigning the existing ones.