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 shouldn't we have a #if .... #else .... #endif construct in Emacs Lisp? Date: Wed, 30 Aug 2023 22:07: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="34425"; 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 Thu Aug 31 04:07:56 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 1qbX6B-0008hV-Hz for ged-emacs-devel@m.gmane-mx.org; Thu, 31 Aug 2023 04:07:55 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qbX5P-0003G9-0h; Wed, 30 Aug 2023 22:07:07 -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 1qbX5N-0003Fc-DD for emacs-devel@gnu.org; Wed, 30 Aug 2023 22:07:05 -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 1qbX5M-00069z-RE; Wed, 30 Aug 2023 22:07:04 -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=KJG4op9Vq2WHbU2uWyEw9B8Od9alO92Od3wMAeWD0vA=; b=ZvIRcKwF6Ql7 1AzsXLHP43dts85J37mqu8Q8jEK/Jdw6J6pAAorKjQgRymVpK+XnkWXJkXPC4up6gAiUKW9RtXnbk I1OccJnoEP3JSUNmAClI9Xngjr//2pJtr7LM4neNbIim5OOnOxGxDLJi2WCMqm+klCzNkIZCHNBGb 480miuS88/N0Irq8IHOuo8GzlYVfH+R3nSUKqOGnm4nC9OPg99TFUU/XqGFJ9r4GgQCXj4zbcTG5Y LTqQEcSpImmerBQn4Xbr3CyBNYK96RPolwCeJFY5DaESoh4KoDxZw4CM7MoI0M/Dl5z1G2FKMdP3O SM0XjNXGtW5HDK4XwyXe4Q==; Original-Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1qbX5M-0003CP-EL; Wed, 30 Aug 2023 22:07:04 -0400 In-Reply-To: (message from Alan Mackenzie on Mon, 28 Aug 2023 21:46:46 +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:309577 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. ]]] > > (when (eval-when-compile (< emacs-major-version 24)) > > (defadvice .....)) > However, when evaluating the containing defun/defmacro rather than byte > compiling it, the irritating warning message will appear with the e-w-c > strategem, but not with hash-if. ;-) How about making the byte compiler recognize the construct (if (< emacs-major-version NUMBER) ...) and do this optimization on it? I think that will DTRT when compiled and when interpreted, and it won't require changes in the code of the programs that use it. That will handle `when' and `unless', since they expand into `if'. It may be necessary to implement this in two places, one for inside of function bodies and one for top level (outside of function definitions). But the code for this should be so short that having two is hardly much loss. -- 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)