From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Why have a #if .... #else .... #endif construct in Emacs Lisp, when we could make the existing code DTRT unchanged? Date: Thu, 07 Sep 2023 21:01:04 -0400 Message-ID: References: Reply-To: rms@gnu.org Content-Type: text/plain; charset=Utf-8 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18500"; mail-complaints-to="usenet@ciao.gmane.io" Cc: ulm@gentoo.org, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 08 03:01:38 2023 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 1qePsP-0004f2-6P for ged-emacs-devel@m.gmane-mx.org; Fri, 08 Sep 2023 03:01:37 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qePrx-0003U7-Sj; Thu, 07 Sep 2023 21:01:09 -0400 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 1qePrv-0003TZ-6e for emacs-devel@gnu.org; Thu, 07 Sep 2023 21:01:07 -0400 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 1qePru-00055S-CV; Thu, 07 Sep 2023 21:01:06 -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=FlGMcAfMtTXcsY59fAlTgH/5YNbvbLKXw4tSpnJ0aKw=; b=VBt2EkvUUPRr Wpqrpwm8xSPFnK+/YUBmncxuaeXtc0Td8N8afWpEi6rp6cluMFgXGqzZnP9TWOj2NuWhDvrm94py3 uYZjltzI+bj7iyXpg0AnE0oud3ZYgY9MYNd7Z1U08wZZqAEfxkiJaqIRfkJbbHuIbT1ZcAbyqh7+6 YdXkAW9XNbzoLJJ24f4rIvJpnmOjLW47zLCFTl+++Q9rdCTqgTz3jgYNHpG1jVK6GF+IFbVZ6juS2 josbVJBIxxslM/2DlSA+j1xKHim/Vyi0filKZaKkpZePn7oW+T5sKwitABn80v2+Lw4SZjPeGWmih cNfa5lCBjOSDpu2bQL/JmA==; Original-Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1qePrs-0006ag-CE; Thu, 07 Sep 2023 21:01:04 -0400 In-Reply-To: (message from Alan Mackenzie on Tue, 5 Sep 2023 14:11:06 +0000) 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:310300 Archived-At: [[[ 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. ]]] If you want to convert most of the existing version conditions to feature tests, in general I don't object. But there is one thing to watch out for: in each instance, it can happen that a feature test is kludgy and a version test is cleaner. It can also happen that a version test is kludgy and a feature test is cleaner. So it could happen that, after converting 40 version tests to feature tests that are natural, there will be 5 remaining version tests that are better left as version tests. Or there might be 10 such, or none such. It might be better to leave a few of them as version tests while converting the rest. Optimizing these tests to operate at compile time is a separate issue. Please DON'T introduce a new construct `static-if' -- instead please make the compiler optimize the constructs that are already in the code. That can be done for feature tests, or for version tests, or for both. It won't be difficult. Why link these two issues? Your last message still presumes using `static-if' but it shows no advantage in that choice. For instance, > It was actually the first thing I considered when the original problem > occurred to me. We have a similar optimisation in place for (featurep > xemacs). But then, the number of ways emacs-major-version (to say > nothing of emacs-minor-version) can be used is large (starting with <, > <=, >, >=, =, /=, eq, eql, equal, and extending to predicates involving > e-minor-v), that it would be at least somewhat difficult to apply in > practice. I don't see an argument there for `static-if' instead of handling `if' at compile time (assuming the actual conditional is the same either way, which it can be). Likewise, here > We could convert (some of) those 45 to use static-if in > less time than it would take to amend the interpreter and byte-compiler > to handler emacs-major-version specially. Maybe so, but the latter would be cleaner. Also, if some if those 45 are converted to feature tests, this issue will be smaller, If only 5 version tests remain, the number of ways such tests are expressed will be at most 5, and they could easily be reduced to 1 or 2. -- 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)